Ts=new reward pulser

[TimSheard]

Addresses issue #4191

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated
• When applicable, versions are updated in .cabal and CHANGELOG.md files according to the
  versioning process.
• The version bounds in .cabal files for all affected packages are updated. If you change the bounds in a cabal file, that package itself must have a version increase. (See RELEASING.md)
• All visible changes are prepended to the latest section of a CHANGELOG.md for the affected packages. New section is never added with the code changes. (See RELEASING.md)
• Code is formatted with fourmolu (use scripts/fourmolize.sh)
• Cabal files are formatted (use scripts/cabal-format.sh)
• hie.yaml has been updated (use scripts/gen-hie.sh)
• Self-reviewed the diff

[lehins]

@TimSheard and @dnadales
So, what is the future of this PR? Do we want to switch the behavior of the pulser or was this just an experiment that we n o longer need to pursue?

[dnadales]

@TimSheard and @dnadales So, what is the future of this PR? Do we want to switch the behavior of the pulser or was this just an experiment that we n o longer need to pursue?

If we could change the behaviour of the pulser, that might help us reduce the number of leadership checks missed in block-producing nodes, so I'd say it makes sense to run a benchmark with a pulser that does not need to be evaluated when taking snapshots.

If we have a ledger version to integrate with Consensus, I can run the benchmarks.