Add MuxError handling in FoldBlocksError

[carbolymer]

Changelog

- description: |
    Add MuxError handling in `FoldBlocksError`. Rename `LedgerStateCondition` to `ConditionResult`.
# uncomment types applicable to the change:
  type:
  # - feature        # introduces a new feature
   - breaking       # the API has changed in a breaking way
  # - compatible     # the API has changed but is non-breaking
  # - optimisation   # measurable performance improvements
   - refactoring    # QoL changes
  # - bugfix         # fixes a defect
  # - test           # fixes/modifies tests
  # - maintenance    # not directly related to the code
  # - release        # related to a new release preparation
  # - documentation  # change in code docs, haddocks...

Context

Moves handling of errors removed in

• Simplify epoch state diff logging cardano-node#5863

to cardano-api. Seems that linking of epoch state logging thread sometimes results in errors:

MuxError MuxBearerClosed "<socket: 71> closed when reading data, waiting on next header True"

or

Exception: ExceptionInLinkedThread (ThreadId 54) (MuxError (MuxIOException writev: resource vanished (Broken pipe)) "(sendAll errored)")

e.g. https://github.com/IntersectMBO/cardano-node/pull/5869/checks?check_run_id=25887156950. This change should let that error be captured by FoldBlocksError.

Also follow-up from

• Change watchEpochStateUpdate callback type cardano-node#5855

to make LedgerStateCondition more reusable.

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated. See Running tests for more details
• Self-reviewed the diff

[carbolymer]

I'm not super satisfied with those names. Any suggestions are welcome here.

[palas]

For fromConditionResult you could call it: isConditionMet or wasConditionMet. For toConditionResult, I am not sure what could be better, one idea would be simply conditionResult, because it is kind of a smart constructor. Or conditionResultMet?

[palas]

But it doesn't look like it is being used

[smelc]

Those names are fine to me. Explicit and not too long. I'd keep them 👍

[carbolymer]

They're meant to be used in cardano-testnet if needed. Example usage:

fooCallbck = do
   ...
   pure $ toConditionResult isSkyBlue

or

fooCallbck = do
   ...
   pure $ conditionResult isSkyBlue

Not sure which one is more obvious. I think I'll stick to toConditionResult as it signals simple conversion.

[palas]

Looks good 👍

[palas]

For fromConditionResult you could call it: isConditionMet or wasConditionMet. For toConditionResult, I am not sure what could be better, one idea would be simply conditionResult, because it is kind of a smart constructor. Or conditionResultMet?

[palas]

But it doesn't look like it is being used

[smelc]

LGTM 👍

[smelc]

Those names are fine to me. Explicit and not too long. I'd keep them 👍

[Jimbo4350]

We should also change the name of this type to something like NewEpochStateError (not necessary for this PR).