avoid attestation queue in fork choice

[arnetheduck]

https://github.com/status-im/nimbus-eth2/blob/d1713031338f4976fdf115721136f9620598afaa/beacon_chain/fork_choice/fork_choice.nim#L232 currently enqueues attestations "from the future" with respect to the current fork choice time.

However, this queue is not necessary: only attestations from the "current" slot end up on it: newer attestations are dropped and older attestations are processed without going through the queue.

A better design would be to collect votes from the "current" slot in a validator-indexed seq[Opt[Vote]] and apply / clear them when the slot changes - this is safe because each validator only gets to vote once per epoch - further, this would avoid allocating a seq for each attestation just to redundantly hold the attesting_indices when in reality, the vast majority of attestations are single-validator updates.

#5288 fixes the immediate and obvious performance problem but the seq allocation is another low-hanging fruit in this context.

[zah]

Wouldn't this seq be quite sparse? A Table may be slightly more economical.

[arnetheduck]

Wouldn't this seq be quite sparse? A Table may be slightly more economical.

it would be 1/SLOTS_PER_EPOCH full most of the time - not sure what would be better between table and seq in that case (ie either is fine in my book probably) - as long as allocations are avoided, any would do I think.

Oh, and of particular note is the fact that when we receive the same vote from both attestation and aggregate (as typically happens), we avoid processing them twice as happens with the queue - both table and seq would do this efficiently.