Bump jruby/joni to 2.2.6

[joegallo]

We haven't touched this in quite some time (it's been since #47374). But there's actually a new feature in joni that we should be taking advantage of: jruby/joni#78 (this PR doesn't do that, though, it's just a version bump).

Interestingly, that previous Elasticsearch PR was also a version bump in order to get access to better timeout logic.

From previous profiling and benchmarking, I know that the grok processor is one of the more time-consuming processors out there, and that while executing the regex is timeconsuming, registering and unregistering the watchdog is surprisingly heavy compared to how long one might imagine it could take (I'm betting due to synchronization overhead), so moving to the native solution without a separate watchdog mechanism would likely buy us a nice little bit of free performance here.

jruby/joni#75 also looks interesting, but I don't know off the top of my head if that's quite as a relevant to our use of joni in Elasticsearch.

[elasticsearchmachine]

Pinging @elastic/es-data-management (Team:Data Management)

[elasticsearchmachine]

Hi @joegallo, I've created a changelog YAML for you.

[masseyke]

LGTM

[masseyke]

It would be useful to attach some kind of performance comparison though.

[joegallo]

Top Processors by Type:
=======================
                       count  time_in_millis  time_in_nanos  percent
processor
grok                50174960          616200          12282    38.7%
grok                50174960          633588          12628    39.4%
grok                50174960          583334          11626    38.6%

Here's an amalgamation of three runs -- the first row is stock Elasticsearch, the second row is slightly slower and that's with the joni upgrade (this might be within the bounds of our confidence interval on these things, 🤷), the third row is with the joni upgrade and I took a quick WIP swing at pulling out the the MatcherWatchdog and replacing it with the new built-in timeout feature from joni. The only values you can compare across the runs are the time_in_millis and time_in_nanos (per document), the percentages are meaningless in this output.

[joegallo]

The purple part is the watchdog part of a Grok#match, and that's what will drop out once we switch to the native timeout solution: