Cardano Updates

  After a deposit snapshot confirms, maybeRequestNextSnapshot fires
  ReqSn(ver=0) immediately. With a 25s network delay, CommitFinalized
  arrives first and bumps the version to 1. The stale ReqSn(ver=0) echo
  is rejected with ReqSvNumberInvalid and nobody re-triggers ReqSn(ver=1),
  leaving the head permanently stuck.

Signed-off-by: Sasha Bogicevic <[email protected]>

  DecommitFinalized aggregate now resets seenSnapshot to
  LastSeenSnapshot{confirmedSn} instead of toLastSeenSnapshot(seenSnapshot).
  This prevents seenSnapshotNumber from advancing to the requested snapshot
  number (which blocked re-requesting), and allows onOpenChainDecrementTx
  to emit a fresh ReqSn with the new version for any pending L2 txs.

Signed-off-by: Sasha Bogicevic <[email protected]>

  After a deposit snapshot confirms, maybeRequestNextSnapshot fires
  ReqSn(ver=N) immediately for pending L2 txs. With a slow network,
  CommitFinalized arrives and bumps the version to N+1 before the echo
  returns. The stale ReqSn(ver=N) is rejected with ReqSvNumberInvalid
  and nobody re-triggers a fresh request, leaving the head stuck.

  Two-part fix mirroring the DecommitFinalized fix:
  - aggregateNodeState: use LastSeenSnapshot{lastSeen=confirmedSn}
    instead of toLastSeenSnapshot, keeping seenSnapshotNumber at the
    confirmed value so the next ReqSn number is correct
  - onOpenChainIncrementTx: add maybeRequestSnapshotAfterCommit so the
    leader immediately sends ReqSn(ver=newVersion) for pending L2 txs
    after CommitFinalized, instead of waiting for the next timer tick

Signed-off-by: Sasha Bogicevic <[email protected]>

This avoids the partial toLedgerTxOut to fail on us in case the user
specifies more output value than input value.

This is to have some more hydra transactions to rollback through

This is currently failing due to partial call to toShelleyTxOut with a
TxOut that has a negative value!

This was the behavior of the commits during the commit phase before and
is now true for all deposits drafted by the node. Note that users can
sidestep this by just creating deposits themselves. This will result in
a deposit just not be picked up (the increment fails validation for
byron addresses) or just work (the mainnet limit is arbitrary).

This reduces test time and should provide same or better coverage.

This is not possible like this anymore. Bob needs to agree on a deposit
and after that version bump, the close with initial is not allowed
anymore. Hence, we cannot have bob lose its state and be able to close
after we saw a version-changing snapshot. In fact, there can't be any
other (non-empty) snapshots because the head starts empty.

In summary, this is not a practical end-user scenario (any more).

Mostly snapshot numbers and timing were off

Until the semantics discussion is resolved

Kept a note about this and bumped seeds from faucet.