state-sync handling in eth/69

[marcello33]

In this PR, we implement the state-sync data handling in the new eth/69 protocol introduced by geth..
Now, nodes have the ability to send state-sync transaction receipts in eth/69 protocol, allowing them to persist the state-sync transaction receipts.

This PR reflects the Erigon's changes for this PR in bor:

• eth, core: handle state-sync data in eth/69 messages bor#1710

[manav2401]

I was navigating the code on how requests are processed and thought of posting some things we need to ensure while testing.

If you follow the path of code on how GetReceipts p2p message is processed (starting from here), there are multiple places at which it tries to find receipts.

1. It tries to fetch it from cache (this is a simple LRU cache). Ideally, I think bor receipts would be generally missing from cache but because there's not mechanism to know that, it would just return from that. We need to ensure that the cache surely contains bor receipts else it won't be included in the p2p packet. I think testing will let us know if this is true or not when we're running a live chain (on devnet or mainnet).

2. It later goes into GetReceipts it uses another layer of cache (which is actually a kv db) making the call to ReadReceiptsCacheV2. We need to ensure that this db contains bor receipts. Again, testing should let us know about this.

3. Worst case if not found, we process the whole block locally to generate receipts and return. I think this should never happen unless user disables a few things via flags. We need to ensure bor tx is also processed via state-sync events stored.

Overall, I think if bor receipts are correctly stored in db / cache, we should be good to go. Let's see how tests go.

[manav2401]

We derive cumulative gas so it may not be zero going forward. It's better to have some different indicator for identifying state-sync transactions.

[manav2401]

I think you can borrow the logic you're using in ReadStateSyncReceiptByHash function here to identify if a receipt is state-sync or not.

[marcello33]

Done here ff196b6
Please double check
Thanks

[manav2401]

This section of code only processes normal transactions. I think we'll need to generate bor receipts by borrowing some logic from here and then append it to the final response of receipts (and also ensure it's updated in cache).

[marcello33]

This section of code only processes normal transactions. I think we'll need to generate bor receipts by borrowing some logic from here and then append it to the final response of receipts (and also ensure it's updated in cache).

Yeah I tried to avoid this in the first place given that the Generator needs a BorGenerator then, and we need to fetch the events again as we do from the jsornpc/API layer.
But I see your point, makes sense.
Addressed here ff196b6, please double check
Thanks

[marcello33]

Closing in favour of #41