Expose ValidationPolicy interface

[jasagredo]

Description

Exposes ValidationPolicy and ComputeLedgerEvents that can be passed to control whether events are computed by the ledger and whether we should enable validation in the ledger layer.

This allows clients of our library to customize these arguments when using our classes (for example someone using the consensus layer to apply blocks in a streamed fashion).

[geo2a]

Overall looks good! I've left one question and several naming suggestions.

[nfrisby]

I'm questioning some things that might lead to a much different diff.

[nfrisby]

I am confused by "At the moment events are not emitted in any case" and then "By passing 'OmintLedgerEvents'" being in the same comment. Are those referring to two different things?

[jasagredo]

I tried to clarify this haddock. Let me know if it looks good

[jasagredo]

This PR is ready for another round of reviews. The final change is that validation options are exposed for the low-level applyBlockLedgerResultWithValidation and hardcoded for everything else. And for the events, those are defaulted to OmitLedgerEvents but eventually we want to expose the function enableLedgerEvents to be used. It is however useless to do it now as there is no handler for those events.

[nfrisby]

Just sharing one key high-level idea.

[nfrisby]

unnecessary parens

[nfrisby]

In my previous comments, I was envisioning something that tightly mimics applySTSOpts https://github.com/IntersectMBO/cardano-ledger/blob/a6f276a9e3df45d69be3a593d3db6cd9dfaa7a02/libs/small-steps/src/Control/State/Transition/Extended.hs#L506-L513 --- so that eg ledger devs can have their same familiar interface

applyStsOptsBlock :: forall ep.
     ApplySTSOpts ep
  -> LedgerCfg l
  -> blk
  -> Ticked l
  -> WithEvents ep (AuxLedgerEvent l) (l, [LedgerErr l]))

type family WithEvents ep ev a where
  WithEvents EPReturn  a = (a, [ev])
  WithEvents EPDiscard a = a

where WithEvents replaces https://github.com/IntersectMBO/cardano-ledger/blob/a6f276a9e3df45d69be3a593d3db6cd9dfaa7a02/libs/small-steps/src/Control/State/Transition/Extended.hs#L278C1-L280C28

---

We could even preserve their exact same signature --- except still taking a config, a block, and a ticked ledger state instead of their RuleContext --- if we wanted to expose their sts/s parameter as an associated type of blk and l, I suppose?

type STS_ApplyBlock blk l :: Type

applySTSOpts_ApplyBlock :: forall ep s.
  (s ~ STS_ApplyBlock blk l) =>
  ApplySTSOpts ep ->
  (LedgerCfg l, blk, Ticked l) ->
  BaseM s (EventReturnType ep s (State s, [PredicateFailure s]))

---

I'm relatively sure that there's no redundancy in that set of inputs, but if there were, then we could change the ApplySTSOpts ep argument to be ``ApplySTSOpts ep -> ApplySTSOpts ep, which the method definition would use to override the default ApplySTSOpts ep` implied by the other arguments?

[jasagredo]

I agree we could go one step further and mimick their interface, but do we need to? I think the expressiveness of the current code is practically the same, isn't it?

[nfrisby]

The assertions are the only difference. There'd be two benefits:

• it'd be more obvious why this function exists
• Ledger could change the definition of these extra arguments (eg add a new parameter) as they see fit, and the only thing we'd need to change is the "default values" we use in a couple places.

[jasagredo]

• So Alexey said explicitly that assertions should use globalAssertionPolicy always and nothing else.
• As for changing the definition, I think the definition is almost entirely stable in the coming future.
• For the why, I could elaborate on the haddock

[jasagredo]

I pushed a commit that modifies the Shelley interface to apply ticks and blocks, and I think the result is satisfactory now. It removes the swizzle helpers. For now I defined the functions from the Ledger PR as undefined.