kaizen: Increase throughput with flexible FA traversal

[timbray]

We took a ~20% performance penalty with the introduction of NFAs (and thus full shellstyle support) and this is shown up particularly in numeric patterns. It turns out that while our data structure is designed to support NFAs, a lot of the FAs we generate are actually deterministic, i.e the combination of a state and a byte always causes a transfer to zero or one other state. Thus it is possible to traverse the FA without keeping track of multiple current/next states, vastly reducing the amount of memory management required. This PR led to ~20% performance improvement on common cases, no change on shellstyle, probably >20% on numerically-heavy patterns. 20% is pretty good since half our CPU/elapsed time still goes into flattening the events.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 88.23529% with 4 lines in your changes missing coverage. Please review.

Project coverage is 96.56%. Comparing base (c28897d) to head (b151669).

Files	Patch %	Lines
value_matcher.go	75.00%	1 Missing and 2 partials ⚠️
small_table.go	87.50%	1 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #332      +/-   ##
==========================================
- Coverage   96.73%   96.56%   -0.17%     
==========================================
  Files          18       18              
  Lines        1837     1864      +27     
==========================================
+ Hits         1777     1800      +23     
- Misses         34       36       +2     
- Partials       26       28       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[timbray]

OK, so I have verified that the benchmark in question, Benchmark_JsonFlattner_Evaluate_ContextFields runs considerably faster as a result of this PR, compared to the previous PR. Looking at the Ci job benchmarks.yml I get the idea that if the comparison fails it refuses to store the output for comparison with subsequent results. Hey, @embano1 and @yosiat, I think one of you set this up. Any suggestions what a good way is to reset the baseline to the value from the last PR, or this one? In the meantime I will probably merge this PR because efficiency is good.

[timbray]

I set fail-on-alert: false in the benchmarks.yml workflow to allow this to succeed, and presumably to reset the cache. If this works, I will set it back to true after pushing this PR. I'm OK with this bit of painful extra work to allow a change that has a performance regression effect, after all they should be very rare.