feat: implement LID block size config

[cheb0]

Description

Allow to configure LID block size.

Fixes #330

---

• I have read and followed all requirements in CONTRIBUTING.md;

[github-actions]

❌ PR Title Validation Failed
Please refer to CONTRIBUTING.md

[github-actions]

❌ PR Title Validation Failed
Please refer to CONTRIBUTING.md

[github-actions]

❌ PR Title Validation Failed
Please refer to CONTRIBUTING.md

[codecov-commenter]

Codecov Report

❌ Patch coverage is 45.00000% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 70.58%. Comparing base (e0cf437) to head (c81db1f).

Files with missing lines	Patch %	Lines
config/validation.go	50.00%	4 Missing and 1 partial ⚠️
cmd/seq-db/seq-db.go	0.00%	2 Missing ⚠️
frac/active.go	0.00%	1 Missing and 1 partial ⚠️
frac/sealed/sealing/blocks_builder.go	0.00%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #405      +/-   ##
==========================================
- Coverage   70.65%   70.58%   -0.07%     
==========================================
  Files         219      219              
  Lines       16967    16985      +18     
==========================================
+ Hits        11988    11989       +1     
- Misses       4084     4096      +12     
- Partials      895      900       +5     

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

I suggest to get rid of this nonsense with Bytes because we do not build blocks by examining size of block but just by examining count of LIDs inside a block:

for _, lid := range lidsbuf {
	// Flush if there is more LIDs than specified threshold.
	if len(a.currentBlock.payload.LIDs) == a.blockCapacity {
		if err := a.onBlock(a.finalizeBlock()); err != nil {
			return err
		}

		a.currentBlock.payload.LIDs = a.currentBlock.payload.LIDs[:0]
		...
	}

	...
}

Migration is gonna be painless since this is how we store this information in .info file:

seq-db ⟩ cat /tmp/tmp.mCJYmApMn2/seq-db-01KREF7BBEPZ0KB0HZZ1CCKP33.info
SEQM{..., "const_lid_block_cap":65536, ...}

What do you think? This is bugging me for a very long time, honestly.

[eguguchkin]

Let's remove this field: Fraction.LIDBlockSize. It is used in a chain that has no functional value: this parameter initializes Info.ConstLIDBlockCap, which is ultimately not used anywhere in the code. Its potential use is for manual debugging: from the console – read the contents of the info block on disk: cat <frac_name>.info.

I propose not to initialize this field at all for the active faction (=0). Initialize it during sealing (see ActiveSealingSource.prepareInfo() method). In the info structure, add a comment that the field is only filled when writing to disk and is not used in the code (so that someone in the future does not build logic around the empty field of the active faction).

[eguguchkin]

nit: Why in the compression section? It seems like we need to make a separate section like Sealing or InvertedIndex or Fraction. And move Compression there as well.