Optimize ReserveSample Function

[nugaon]

Task

Optimize the ReserveSample function in the Bee node to improve performance and reduce resource consumption. This function is critical for node operators participating in storage incentives, but currently runs too slowly to complete within required lottery round time constraints (issue #5132). Performance bottlenecks in sample fetching negatively impact node operators and contribute to higher staking requirements (issue #4849).

Acceptance criteria

• Sample generation completes within lottery round time constraints
• Reduced resource (CPU, memory etc.) usage during sampling process
• No regressions in sample correctness
• Performance metrics showing improvement compared to baseline

[acud]

I am working on this ticket. There's already a few directions for optimization here.
One this is missing and that's at least some basic benchmarks on the current performance, this is added with #5374.

Also, optimizing stuff here on the level of the actual ReserveSample function is like throwing stones at a tank. The major problems here are: 1. the BMT hasher. 2. the memory allocations generated by iterating over the chunks that need to be sampled.

Regarding the BMT hasher, there are several inefficiencies:

1. it spins up massive amount of goroutines for every hashing operation (every node = goroutine = 255 goroutines per chunk). This means 256 allocations for a 4k chunk
2. this pressures the GC and the scheduler

I already have a solution for this. Currently for Linux amd64 only. I've compiled the XKCP AVX implementations of keccak (SIMD) into assembler code and found a way to reference them from the go code without using cgo (direct assembler code). There's a significant improvement there already, but it needs further testing.

Regarding the memory allocations:

1. The fact that there's an iterator on the reserve sample method causes massive amounts of allocations needed in order to move chunk data to that method from the storage.
2. This is opposed to it fitting on the stack (so it does not escape).
3. We could move the majority of those hashing operations down the call stack and "closer" to the data, allowing the hashing to happen with the data on the stack, returning only the transformed addresses together with the chunk addresses. The chunks that are needed for the proofs (very little) could then be individually fetched from the storage and put through the prover, minimizing the memory stress on the application.

[acud]

The SIMD hasher has been merged. There's one more improvement I would try to get merged and that is to move the ReserveSample iterators into the reserve, and change with it also the Getter interfaces (or extend them) with an interface that reads directly into a buffer (that can be reused).
Some sort of an example can be seen on trymove-logic-closer branch. Although some of the changes probably aren't strictly needed. This should be done hand-in-hand with a constant benchmark using the existing benchmark in the package (together with the changes, shelved one by one to see what makes an impact).