Speed up request buffered hashes

[emhane]

closes #6148. closes #6308.

speeds up requesting buffered hashes by

- [x] dividing hashes store (unknown_hashes, buffered_hashes[ and meta]) into eth68 and eth66. this means only hashes will be traversed that can be included in the request being assembled in fill_request_from_buffer_for_peer.

• improve performance and maintainability at cost of allocating memory for metadata for all hashes, regardless if seen in eth66 announcements only and hence have no metadata.
• use the transactions list on Peer type to search buffered_hashes after pop_any_idle_peer returns. that cache has capacity 10 240 and buffered hashes has capacity 25 600. also, then we just have to search buffered hashes, and not nested lists (even if they just default to 3 elements long) in buffered hashes for our peer returned by pop_any_idle_peer. effectivity of this is up to how well we can update the transactions list in the Peer type on-op. we will only update the transactions list on Peer type when we need to touch it anyway, on-op. we won't move around elements in lists of peer's seen transactions. it serves only as a hint to which hash cannot be pending, not as a perfect list of which hashes are pending. this totally satisfies requirements and otherwise it doesn't scale.

[mattsse]

this is still very expensive because we blindly iterate all hashes in the hope the peer is the fallback, can we not keep track of the peer's hashes instead when registering them as fallback peers?

[emhane]

this is still very expensive because we blindly iterate all hashes in the hope the peer is the fallback, can we not keep track of the peer's hashes instead when registering them as fallback peers?

yes, this is step 2 as mentioned above. the peer's hashes are already tracked in Peer type. possibly we add a new list which is a subset of Peer { transactions, .. }. two new lists to be precise, since storing them eth66 and eth68 in same list is counterproductive.

[emhane]

this is still very expensive because we blindly iterate all hashes in the hope the peer is the fallback, can we not keep track of the peer's hashes instead when registering them as fallback peers?

we don't even need to register any peer as fallback peer in that case, it's just double up storage of same data that can be derived by checking peer's seen txns against buffered hashes (buffered as in buffered for re-fetch or for first fetch if the hash didn't fit in the request that was triggered by processing the announcement in which the hash was seen the first time).

[emhane]

This is how the branch is looking on mainnet rn.

This is samply at commit 739d3c1
https://share.firefox.dev/3STlLDb

Will update with new samply from latest commit later.

[Rjected]

Will do a more comprehensive review soon, but I just saw these constant names and wanted to see if they could be made shorter

[Rjected]

I like the documentation on these but these names are gigantic, is there any way to make this more concise?

[emhane]

yeah I know they are, but not having enough info can cost a lot of time since then they are interpreted wrong. we already had this with some other constants recently. will eventually change some of these to const functions anyway, then we can asses the lengths again.

[onbjerg]

lgtm

[mattsse]

sharing @Rjected view that some names are gigantic, but can bikeshed separately.

lgtm, nice work