benchmark TICKF

We need realistic benchmarks of the `TICKF` rule in order to determine if #3034 is a real problem.

---

The consensus layer calls `TICKF` once per slot to determine if a block producing node has been elected leader. When the slot in question is in a new epoch (relative to the last ledger view that the consensus layer has stored), this results in a potentially expensive computation (see #3034).

`TICKF` is defined here (every ledger era has used the Shelley TICKF):

https://github.com/input-output-hk/cardano-ledger/blob/1176affe9b2a7a3b50c1ceda00cc92f237ea6360/eras/shelley/impl/src/Cardano/Ledger/Shelley/Rules/Tick.hs#L262

---

In order to get realistic data for our benchmarks, we can use [db-analyser](https://github.com/input-output-hk/ouroboros-network/blob/master/ouroboros-consensus-cardano-tools/Documentation.md) to get the ledger state on mainnet just before some of the epoch boundaries. The benchmarks will deserialize the ledger state obtained from db-analyser, and project the `NewEpochState` for use in the `TICKF` rule.

Some slots we might consider (this issue was created in the middle of epoch 363):

|slot number| block number| last block of epoch X|
|---|---|---|
|71452796|7749373|362|
|71020795|7728107|361|
|70588777|7706865|360|
|70156668|7685639|359|
|69724795|7664616|358|

Note that the benchmarks will need to use a `Slot` past the epoch boundary in order to trigger the large calculations.

---

Tasks:

- [ ] Write a tool that takes a ledger state snapshot from db-analyser and benchmarks the `TICKF` rule.
- [ ] Create ledger state snapshots for the slots in the table above.
- [ ] Record the times obtained from running the new tool on the snapshots. (The report can be placed in this GitHub issue.)