Improve recomputeForkChoiceHead

[twoeths]

Describe the bug

In mainnet node it could take up to 0.5s to recomputeForkChoiceHead

and it takes 6% of cpu in total

while out benchmark says <= 100ms

see #5836 (comment)

Expected behavior

Get back to the level of v1.9.x

Steps to reproduce

No response

Additional context

No response

Operating system

Linux

Lodestar version or commit hash

v1.10.0

[twoeths]

this could be because we processed so many attestations in v1.10.0 compared to v1.9.2

also looks like the benchmark test does not go with this number, need to update it

[twoeths]

this is part of the effort to handle more validators coming to ethereum, see #5855

[twoeths]

for 2M validator network, this could be up to 8s on 2M validator devnet

[twoeths]

0810_updateHead_perf_test.cpuprofile.zip

this issue is caused by getAncestor() call, we iterate too much from a node until finalized node to check if a node is descendant of finalized node

[dapplion]

@tuyennhv please research the following:

• when changing finalized create a new nodes vector that includes only descendant of finalized
• keep a mapping of the node index changes and update all indexes

With this we pay a higher ocassional cost, but then we never have to check if descedant of finalized. My concern is that finalized checkpoint can change at times where the node is hot. But it should be worth it to benchmark how expensive this remapping operation is