XCOMMONS-2349: Improve performance of AttributeFilter in HTMLCleaner

[michitux]

This includes two implementations in two commits, the first is based on ThreadLocal, which is changed to use the execution context in the second commit, which I believe should be the better option. As it is not clear that XPathFactory.newInstance(); is thread-safe, I have also added a synchronized-block which should also be added to all other uses if we agree that this is an issue.

Note: I'm not sure that this is the right approach. I'll stop investigating here for now, but I did a quick profile (in debug mode, no idea how much this impacts performance) of the 1000 HTML macros test page and it seemed to me as if XPath evaluation accounts for almost 90% of the HTMLFilter running time. This is quite bad imho as HTMLFilter still needs about as much time as the rest of the Macro transformation. I think this is way too much even though it is a roughly factor 10 improvement (factor 5 overall less running time). Therefore, we might either need to cache even more (maybe cache the XPathExpression as in the first commit, didn't benchmark that) or use a different implementation for this filter.

Jira issue: https://jira.xwiki.org/browse/XCOMMONS-2349

[michitux]

Removed the synchronized-block after a discussion in #xwiki.

[michitux]

I've just pushed a new version that simply doesn't use any XPath after having learned how to traverse the DOM in another context. In my personal opinion the code isn't more complicated, in fact imho it is much simpler than the version that cached the XPath-Factory. The only thing I didn't check is if there are penalties due to modification of the DOM during the iteration as the DOM list is live. Benchmarks with 100 runs on current 14.5-SNAPSHOT:

Before 1000HTMLMacros:
0.26493 +- 0.00230 seconds

After 1000HTMLMacros:
0.083247 +- 0.000539 seconds

As comparison 1000Macros:
0,051540 +- 0,000744

A short profile shows that org.xwiki.rendering.internal.transformation.XWikiRenderingContext#getTargetSyntax which is called twice by the HTML macro takes about 50% of the running time of the HTML macro. When I wrote the code that calls it I expected this to be a simple property read and not something expensive that reads a configuration option and loads a document (from the cache) to get an XObject.