feat(op-node): pre-fetch block info and transaction

[welkin22]

Description

In #100 and #104, I modified the pre-fetch logic for receipts. Based on metrics, we found that the performance of the block info and transaction retrieval APIs is also poor when L1 load is high. We need to fetch this data in advance and put it into cache. As the InfoAndTxsByHash is called in the FetchReceipts interface, the pre-fetch logic for block info and transaction data has already been performed in the receipts. I just need to make some modifications to the existing unreasonable parts to make pre-fetch effective for block info and transactions.

Rationale

LRU cache is not applicable in all cases, so I added the bool parameter isReadOrderly to EthClient. When we request L1 from our EthClient, we request the data in order of block height, so isReadOrderly should be true. When we request L2 from our EthClient, we do not request in order of block height, so isReadOrderly should be false. When isReadOrderly is true, the LRU cache should not insert the most recently accessed block at the front of the queue, causing the data in the queue to not be sorted in order of block height(When the LRU cache is full, the queue sorted in block height order can help us eliminate old and no longer needed block heights). Therefore, I use Peek instead of Get method to avoid this situation.

Example

none

Changes

Notable changes:

1. LRU cache is not applicable in all cases, so I added the bool parameter isReadOrderly to EthClient. When isReadOrderly is true, I use Peek instead of Get method in LRU cache.
2. During pre-fetching, I do not track metrics, so our metrics panel can show the true hit rate.
3. There are currently some issues with the devnet running, as BSC has deleted the test-crosschain-transfer repository, which we actually did not use. Therefore, I have removed it from the dockerfile. At the same time, we have switched to using the develop branch of geth, so that we can use the latest code for testing.

[welkin22]

Due to some merge conflicts in #110, it was difficult to resolve them. Therefore, I have resubmitted a new branch.
@bnoieh @owen-reorg Please help review