Cache cycle retrieval RPC for nonce revelation

Context

This MR optimizes a costly RPC made by the baker at each new block that request all block hashes of the previous cycle from the node: this is used to check whether to reveal a nonce or not. This patch acts as a temporary fix until the nonce revelation worker gets a (much needed) refactor. The fix consists in adding a small simple cache.

Benches made on my (reasonably powerful) machine -- On less performant machines, it was observed that it could take up to 2s. Before

blocks from current cycle ................................................ 1          131.430ms
blocks from current cycle ................................................ 1          124.182ms
blocks from current cycle ................................................ 1          118.490ms
blocks from current cycle ................................................ 1          127.860ms
blocks from current cycle ................................................ 1          115.557ms

After

blocks from current cycle ................................................ 1          108.452ms
blocks from current cycle ................................................ 1            4.653ms
blocks from current cycle ................................................ 1            6.214ms
blocks from current cycle ................................................ 1            4.085ms
blocks from current cycle ................................................ 1            4.843ms

The first call computes and puts in cache the resulting RPC. The following calls show that the cache is hit and the value is directly retrieved -- the 5ms is explained by the fact that we still need to make a RPC call to the node to determine the current cycle.

Manually testing the MR

CI

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR