feat: pagination using offset-id

[cheb0]

Description

A new way to paginate through logs which is similar to Elasticsearch search_after feature. A user can take doc ID from the last doc on the page and use it as offset for the next page. The field is called offset-id: the first part offset outlines that it provides offset feature, the part id points that it's a doc ID.

Measurements

Our benchmarks

seq-db-paging.js

   http_req_duration..............: avg=1.98ms   min=786.02µs med=1.8ms    max=6.08ms   p(90)=2.87ms   p(95)=3.58ms
      { expected_response:true }...: avg=1.98ms   min=786.02µs med=1.8ms    max=6.08ms   p(90)=2.87ms   p(95)=3.58ms
   http_req_duration..............: avg=2.01ms   min=688.64µs med=1.83ms   max=9.66ms   p(90)=2.92ms   p(95)=3.28ms
      { expected_response:true }...: avg=2.01ms   min=688.64µs med=1.83ms   max=9.66ms   p(90)=2.92ms   p(95)=3.28ms

seq-db-offset-id.js (new)

    http_req_duration..............: avg=1.33ms   min=569.57µs med=1.17ms   max=4.46ms   p(90)=2.07ms  p(95)=2.61ms
      { expected_response:true }...: avg=1.33ms   min=569.57µs med=1.17ms   max=4.46ms   p(90)=2.07ms  p(95)=2.61ms
    http_req_duration..............: avg=1.29ms   min=604.71µs med=1.13ms   max=4.18ms   p(90)=1.98ms   p(95)=2.37ms
      { expected_response:true }...: avg=1.29ms   min=604.71µs med=1.13ms   max=4.18ms   p(90)=1.98ms   p(95)=2.37ms

Elasticsearch

Currently, it's unable to cope with 20 concurrent readers (all CPU is used) but even with a single reader it's slow. Will investigate later.

   http_req_duration..............: avg=4.19s min=1.35ms med=3.86s max=8.27s p(90)=4.25s p(95)=7.6s
      { expected_response:true }...: avg=4.19s min=1.35ms med=3.86s max=8.27s p(90)=4.25s p(95)=7.6s
   http_req_duration..............: avg=4.18s min=1.05ms med=4.06s max=8.22s p(90)=4.23s p(95)=4.8s
      { expected_response:true }...: avg=4.18s min=1.05ms med=4.06s max=8.22s p(90)=4.23s p(95)=4.8s

Results for other data

k8s_pod:payment-backend-* AND level:4, scroll 50 pages 100 logs each (cold run after seq-db restart)
2114 ms (offset) vs 1729 ms (offset-id)
k8s_pod:payment-backend-1 AND level:2, scroll 50 pages 100 logs each (cold run after seq-db restart)
468 ms (offset) vs 166 ms (offset-id)

Fixes #262

---

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

If you have used LLM/AI assistance please provide model name and full prompt:

Model: {{model-name}}
Prompt: {{prompt}}

[codecov-commenter]

Codecov Report

❌ Patch coverage is 77.77778% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.07%. Comparing base (001283c) to head (eb2240c).

Files with missing lines	Patch %	Lines
seq/seq.go	57.14%	4 Missing and 2 partials ⚠️
storeapi/grpc_search.go	78.94%	3 Missing and 1 partial ⚠️
proxyapi/grpc_v1.go	50.00%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #278      +/-   ##
==========================================
- Coverage   71.16%   71.07%   -0.09%     
==========================================
  Files         201      201              
  Lines       14773    14823      +50     
==========================================
+ Hits        10513    10536      +23     
- Misses       3515     3536      +21     
- Partials      745      751       +6     

☔ 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.

[forshev]

seems like missed debug print

[cheb0]

nice catch, bro