eth: fix canonical chain state inconsistency in checkpoint verifier

v2.2.5 - backport to develop

core/types: bumped fakesigner from london to prague

Add flags from upstream (geth) which control data retention for transactions, logs, and state. Also, add a deprecation notice for `txlookuplimit` flag which will be replaced by `history.transactions` flag in next release.

Signed-off-by: gopherorg <gopherworld@icloud.com>
Co-authored-by: Manav Darji <manavdarji.india@gmail.com>

Use a simple atomic flag for handling commit interrupt instead of using context based timeout. Internal benchmarks revealed that checking for `context.Done()` for every OPCODE leads to 40% CPU usage (out of the total CPU used in block building loop) which is not very optimal. Instead of context, a pointer to this atomic flag is passed and is toggled when the block building time is completed to interrupt. 

This also allows us to simply the use of commit interrupt and the worker - evm interaction.

backport v2.2.8

This resolved a possible race condition when a milestone reorg happens at the same time when a validator mines a new block. The miner should be completely stopped when setHead canonical head and inserting finalized chain.

…og (#1636)

- Skip stale sealed blocks that are behind current chain head to prevent
    resultLoop from attempting to write outdated blocks after reorgs
  - Add 1-second timeout to chDeps channel send to prevent indefinite
    blocking when receiver is dead or channel is full
  - Return error when transaction count exceeds dependency list length
    to prevent array index out of bounds panic

  These fixes address production issues where mining nodes would deadlock
  for hours after milestone-triggered reorgs, unable to
  process new blocks or respond to chain updates.

* debu logs

* debug logs

* debug logs for trace start of grpc

* grpc start after backend assignment

* removing logs

* fix tests