Attestation aggregation: optimizations and benchmarks

[farazdagi]

What type of PR is this?

Bug fix
Feature
Other/Refactoring

What does this PR do? Why is it needed?

In this PR:

• optMaxCoverAttestationAggregation() method is added. See https://hackmd.io/@farazdagi/in-place-attagg for details on design of that optimized aggregation procedure. Once this feature is tested, optMaxCoverAttestationAggregation() will replace existing Bitlist based implementation.
• New flag value (opt_max_cover) for attestation-aggregation-strategy flag has been added (flag is tracked via Feature flag tracking: attestation-aggregation-strategy=opt_max_cover #8365). So, new aggregation is used when one of the following is set:
  • attestation-aggregation-strategy=opt_max_cover
  • --dev
• E2E tests are also configured to rely on a new optimized max-cover.
• ❗ It should be safe to merge this PR, in a sense that it affects only --dev mode of beacon node.

PRs extracted from this PR:

• Performance benchmarks Attestation aggregation: maxcover vs naive aggregation effectiveness test #8043
• Fix issue with proper sets Attestation aggregation: remove proper set duplicates #8063
• Baseline benchmark (max-cover vs naive) Attestation aggregation: baseline benchmark #8308
• Clock-time benchmarks Max-cover: optimized implementation based on Bitlist64 #8352
• More optimized validation of incoming attestations Attestation Aggregation: optimize attestation list validation #8213
• Max-cover on attestation selection by proposer (will be tackled separately in Improvements in proposer's attestation selection routine #8353)

Which issues(s) does this PR fix?

Fixes #7871

Other notes for review

• It is very hard to benchmark the Aggregation() function, because it updates attestations in place, so for each bench mark run you need to create another copy of attestations lists (and when using b.StopTimer()/b.StartTimer() inside the for i := 0; i < b.N; i++ loop -- so that each case gets its own copy -- benchmarks seem to hang.
• So, attestation copying was put inside as a part of benched function, but that copying is more heavy than aggregation itself, so results on number of operations completed are only relatively useful.
• Still, benchmarks allow to see the difference in allocations (which was the purpose of this optimization -- get rid of unnecessary allocations), so benchmarks are still useful:
  

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[rauljordan]

Went through this a few times and feel really good about it. It is also very well gated behind flags and I know you put in a lot of thought into this. Excited to see it integrated into runtime and for future PR's!

[farazdagi]

Went through this a few times and feel really good about it. It is also very well gated behind flags and I know you put in a lot of thought into this. Excited to see it integrated into runtime and for future PR's!

Thank you!