perf: improve wildcard query perf with predicate and contains-check pushdown

[cheb0]

Description

Currently we spend only a fraction of time calling bytes.Index. This PR partially addresses that.

This PR pushes pattern.Searcher to Block level, so that Block is able to stream tokens through searcher. For ordinary wildcards like *error* there is direct FindContains method which is even faster.

For example, query message:*foobarf*:
main: 86 ms
using FindToken: 50 ms
using FindContains: 37 ms

So, FindContains just throws out costly abstractions to get additional performance. We could also provide a dedicated func like FindSuffix, for example. This is a typical example when performance requires additional code.

Query	Type	Ids	cold, ms	hot, ms	cold (branch), ms	hot (branch), ms	cold diff	hot diff
trace_id:*foobar	reg	0	18.76	4.37	16.14	1.84	-14%	-57.9%
k8s_pod:*6	reg	100	13.3	0.67	13.03	0.47	-2%	-29.9%
message:*err*	reg	100	138.72	26.97	120.27	12.36	-13.3%	-54.2%
message:*foo*	reg	100	77.69	27.08	60.54	11.84	-22.1%	-56.3%
message:*request*	reg	100	124.95	25.45	104.13	10.37	-16.7%	-59.3%
message:*foobar*foobar*	reg	0	187.54	64.25	147.31	30.5	-21.5%	-52.5%
message:*foobarfoobar*	reg	0	184.93	63.87	121.51	20.39	-34.3%	-68.1%
message:*very_very_message_aggregator_events*	reg	0	173.45	51.62	116.9	12.81	-32.6%	-75.2%

Next steps:

• try calling bytes.Index over Block payload - already shows good results
• build Offsets lazy - if previous is done
• modernize token Block, boost Unpack speed

---

• I have read and followed all requirements in CONTRIBUTING.md;
• I used LLM/AI assistance to make this pull request;

[codecov-commenter]

Codecov Report

❌ Patch coverage is 88.46154% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.51%. Comparing base (5115f7b) to head (cee0a60).

Files with missing lines	Patch %	Lines
frac/active_token_list.go	78.94%	2 Missing and 2 partials ⚠️
frac/sealed/token/provider.go	91.48%	2 Missing and 2 partials ⚠️
frac/sealed/token/block_loader.go	86.66%	1 Missing and 1 partial ⚠️
pattern/pattern.go	91.30%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #397      +/-   ##
==========================================
+ Coverage   71.28%   71.51%   +0.22%     
==========================================
  Files         210      210              
  Lines       15579    15662      +83     
==========================================
+ Hits        11105    11200      +95     
+ Misses       3673     3663      -10     
+ Partials      801      799       -2     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[dkharms]

We've discussed that you can perform bytes.Contains on the block payload before checking each token individually. Have you measured performance of such optimization?

[cheb0]

We've discussed that you can perform bytes.Contains on the block payload before checking each token individually.

Yes, I tried calling bytes.Index on entire payload. It boosts even further comparing to this PR:
message:foobar
35 ms => 9 ms

However, this means that when bytes.Index returns and if we have some proper index returned, then we need to do a bin search on Offsets to find an index and then check for false positive. It also comes with neat property that we can avoid call Unpack (build offsets) lazily which boosts cold query performance (somewhat around extra 20%).

I put a task to the backlog, decided that it's too much for a single PR.

[dkharms]

I guess you could pass here slice of needles as well to handle queries like message:*foo*bar* with multiple needles. Or there is something that blocks such improvement?

[cheb0]

No, I think it's doable. Maybe will do