feat(fracmanager): implement fraction snapshots with wait group reference counting

[eguguchkin]

Fixes #275

---

• 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 80.23952% with 33 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.67%. Comparing base (1744059) to head (38a7993).

Files with missing lines	Patch %	Lines
fracmanager/fraction_registry.go	80.00%	10 Missing ⚠️
fracmanager/lifecycle_manager.go	62.50%	8 Missing and 1 partial ⚠️
fracmanager/fractions_snapshot.go	81.81%	5 Missing and 1 partial ⚠️
fracmanager/sync_appender.go	75.00%	4 Missing and 2 partials ⚠️
fracmanager/fracmanager.go	85.71%	0 Missing and 1 partial ⚠️
storeapi/grpc_async_search.go	75.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #277      +/-   ##
==========================================
+ Coverage   71.65%   71.67%   +0.02%     
==========================================
  Files         204      205       +1     
  Lines       14770    14735      -35     
==========================================
- Hits        10583    10562      -21     
+ Misses       3435     3423      -12     
+ Partials      752      750       -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.

[github-actions]

🔴 Performance Degradation

Some benchmarks have degraded compared to the previous run.
Click on Show table button to see full list of degraded benchmarks.

Show table

Name	Previous	Current	Ratio	Verdict
FindSequence_Random/small-4	174405	3d34b5
	10280.15 MB/s	7073.38 MB/s	0.69	🔴
	24.90 ns/op	36.19 ns/op	1.45	🔴
GenerateDocs-4	174405	3d34b5
	952.20 ns/op	1142.00 ns/op	1.20	🔴

[cheb0]

If search panics, then release() is never called.

[cheb0]

What happens in the following scenario:

• we already have a snapshot built - S1
• search request arrives
• while search request is being executed, snapshot rebuild is called. Let's call it S2
• now we overwriting a wait group inside ...SyncDestroyable struct with S2 wait group.
• at the same time, if we want to destroy a fraction, we call wg.Wait(). But we might issue wait for wait group S2. Since nobody has called wg.Add for a S2 wg, it will return immediately. However, search request might still be working and touch this fraction.

[cheb0]

Besides, we issue s.wg = &fs.wg under fraction registry lock (only a single snapshot can be being under construction at the same time).
However, we read this wg group d.wg.Wait() in Destroy.

i.e. techically it's a data race if understand correctly - it's a unsynchronized read/write of a non-atomic variable. The whole question is what guarantees do we have in Go.

[cheb0]

If we have search request constantly arriving (let's say 5 requests per second) and taking same fraction snapshot. Can we potentially run into any problems?