Sep 21, 10-11 AM (45)
Sep 21, 11-12 PM (19)
Sep 21, 12-1 PM (34)
Sep 21, 1-2 PM (62)
Sep 21, 2-3 PM (83)
Sep 21, 3-4 PM (125)
Sep 21, 4-5 PM (22)
Sep 21, 5-6 PM (35)
Sep 21, 6-7 PM (7)
Sep 21, 7-8 PM (7)
Sep 21, 8-9 PM (10)
Sep 21, 9-10 PM (30)
Sep 21, 10-11 PM (10)
Sep 21, 11-12 AM (0)
Sep 22, 12-1 AM (31)
Sep 22, 1-2 AM (3)
Sep 22, 2-3 AM (3)
Sep 22, 3-4 AM (7)
Sep 22, 4-5 AM (12)
Sep 22, 5-6 AM (16)
Sep 22, 6-7 AM (128)
Sep 22, 7-8 AM (41)
Sep 22, 8-9 AM (95)
Sep 22, 9-10 AM (52)
Sep 22, 10-11 AM (49)
Sep 22, 11-12 PM (42)
Sep 22, 12-1 PM (32)
Sep 22, 1-2 PM (26)
Sep 22, 2-3 PM (25)
Sep 22, 3-4 PM (27)
Sep 22, 4-5 PM (21)
Sep 22, 5-6 PM (11)
Sep 22, 6-7 PM (23)
Sep 22, 7-8 PM (13)
Sep 22, 8-9 PM (9)
Sep 22, 9-10 PM (11)
Sep 22, 10-11 PM (19)
Sep 22, 11-12 AM (11)
Sep 23, 12-1 AM (9)
Sep 23, 1-2 AM (2)
Sep 23, 2-3 AM (15)
Sep 23, 3-4 AM (7)
Sep 23, 4-5 AM (12)
Sep 23, 5-6 AM (10)
Sep 23, 6-7 AM (25)
Sep 23, 7-8 AM (38)
Sep 23, 8-9 AM (34)
Sep 23, 9-10 AM (18)
Sep 23, 10-11 AM (25)
Sep 23, 11-12 PM (38)
Sep 23, 12-1 PM (44)
Sep 23, 1-2 PM (37)
Sep 23, 2-3 PM (95)
Sep 23, 3-4 PM (26)
Sep 23, 4-5 PM (58)
Sep 23, 5-6 PM (15)
Sep 23, 6-7 PM (21)
Sep 23, 7-8 PM (35)
Sep 23, 8-9 PM (16)
Sep 23, 9-10 PM (24)
Sep 23, 10-11 PM (16)
Sep 23, 11-12 AM (7)
Sep 24, 12-1 AM (6)
Sep 24, 1-2 AM (1)
Sep 24, 2-3 AM (6)
Sep 24, 3-4 AM (5)
Sep 24, 4-5 AM (14)
Sep 24, 5-6 AM (19)
Sep 24, 6-7 AM (22)
Sep 24, 7-8 AM (56)
Sep 24, 8-9 AM (27)
Sep 24, 9-10 AM (32)
Sep 24, 10-11 AM (44)
Sep 24, 11-12 PM (25)
Sep 24, 12-1 PM (36)
Sep 24, 1-2 PM (42)
Sep 24, 2-3 PM (29)
Sep 24, 3-4 PM (17)
Sep 24, 4-5 PM (11)
Sep 24, 5-6 PM (26)
Sep 24, 6-7 PM (27)
Sep 24, 7-8 PM (22)
Sep 24, 8-9 PM (12)
Sep 24, 9-10 PM (6)
Sep 24, 10-11 PM (0)
Sep 24, 11-12 AM (2)
Sep 25, 12-1 AM (6)
Sep 25, 1-2 AM (0)
Sep 25, 2-3 AM (0)
Sep 25, 3-4 AM (1)
Sep 25, 4-5 AM (4)
Sep 25, 5-6 AM (3)
Sep 25, 6-7 AM (19)
Sep 25, 7-8 AM (6)
Sep 25, 8-9 AM (7)
Sep 25, 9-10 AM (8)
Sep 25, 10-11 AM (2)
Sep 25, 11-12 PM (1)
Sep 25, 12-1 PM (7)
Sep 25, 1-2 PM (6)
Sep 25, 2-3 PM (15)
Sep 25, 3-4 PM (3)
Sep 25, 4-5 PM (2)
Sep 25, 5-6 PM (6)
Sep 25, 6-7 PM (2)
Sep 25, 7-8 PM (8)
Sep 25, 8-9 PM (2)
Sep 25, 9-10 PM (6)
Sep 25, 10-11 PM (8)
Sep 25, 11-12 AM (8)
Sep 26, 12-1 AM (1)
Sep 26, 1-2 AM (10)
Sep 26, 2-3 AM (0)
Sep 26, 3-4 AM (1)
Sep 26, 4-5 AM (0)
Sep 26, 5-6 AM (11)
Sep 26, 6-7 AM (6)
Sep 26, 7-8 AM (2)
Sep 26, 8-9 AM (9)
Sep 26, 9-10 AM (4)
Sep 26, 10-11 AM (2)
Sep 26, 11-12 PM (1)
Sep 26, 12-1 PM (1)
Sep 26, 1-2 PM (13)
Sep 26, 2-3 PM (4)
Sep 26, 3-4 PM (7)
Sep 26, 4-5 PM (8)
Sep 26, 5-6 PM (2)
Sep 26, 6-7 PM (4)
Sep 26, 7-8 PM (19)
Sep 26, 8-9 PM (16)
Sep 26, 9-10 PM (5)
Sep 26, 10-11 PM (2)
Sep 26, 11-12 AM (1)
Sep 27, 12-1 AM (12)
Sep 27, 1-2 AM (5)
Sep 27, 2-3 AM (1)
Sep 27, 3-4 AM (5)
Sep 27, 4-5 AM (10)
Sep 27, 5-6 AM (35)
Sep 27, 6-7 AM (13)
Sep 27, 7-8 AM (14)
Sep 27, 8-9 AM (17)
Sep 27, 9-10 AM (10)
Sep 27, 10-11 AM (4)
Sep 27, 11-12 PM (14)
Sep 27, 12-1 PM (44)
Sep 27, 1-2 PM (15)
Sep 27, 2-3 PM (14)
Sep 27, 3-4 PM (69)
Sep 27, 4-5 PM (61)
Sep 27, 5-6 PM (10)
Sep 27, 6-7 PM (9)
Sep 27, 7-8 PM (19)
Sep 27, 8-9 PM (10)
Sep 27, 9-10 PM (4)
Sep 27, 10-11 PM (3)
Sep 27, 11-12 AM (2)
Sep 28, 12-1 AM (8)
Sep 28, 1-2 AM (4)
Sep 28, 2-3 AM (29)
Sep 28, 3-4 AM (29)
Sep 28, 4-5 AM (11)
Sep 28, 5-6 AM (11)
Sep 28, 6-7 AM (53)
Sep 28, 7-8 AM (22)
Sep 28, 8-9 AM (35)
Sep 28, 9-10 AM (13)
Sep 28, 10-11 AM (3)
3,154 commits this week Sep 21, 2021 - Sep 28, 2021
Update dependencies.
- cardano-ledger-specs has been reorganised for sanity.
  (https://github.com/input-output-hk/cardano-ledger-specs/pull/2483)
  This entails a number of refactorings:
  - The package 'shelley-spec-ledger' is now deprecated in favour of
    'cardano-ledger-shelley'.
  - Shelley.Spec.NonIntegral -> Cardano.Ledger.NonIntegral
  - Shelley.Spec.Ledger -> Cardano.Ledger.Shelley
  - *.STS -> *.Rules
  - Test.Shelley.Spec.Ledger -> Test.Cardano.Ledger.Shelley

- As per https://github.com/input-output-hk/ouroboros-network/pull/3369,
  there is now no 'FilePath' argument to 'localSnocket'.

- Bump base to include a potential memory leak fix.
Merge #2914
2914: Add updateSealedTx and ExtraTxBodyContent r=Anviking a=Anviking

- [x] Refactoring: Replace `to{Shelley, Allegra, Mary, Alonzo}TxOut` with `toCardanoTxOut` for easier re-use.
- [x] Add `updateSealedTx :: SealedTx -> ExtraTxBodyContent -> Either ErrUpdateSealedTx SealedTx`
- [x] Test that `updateSealedTx noExtraBodyContent` works with all PAB goldens
- [x] Test that `updateSealedTx noExtraBodyContent` fails when there are existing key witnesses
- [x] Test that inputs and outputs are combined correctly. 

### Comments

Not tested:
- That it works for all previous eras.

<!-- Additional comments, links, or screenshots to attach, if any. -->

### Issue Number

ADP-1140

Relates to / should be needed by #2906

<!-- Reference the Jira/GitHub issue that this PR relates to, and which requirements it tackles.
  Note: Jira issues of the form ADP- will be auto-linked. -->


Co-authored-by: Johannes Lund <[email protected]>
Added multinode_Sim_Pruning_HardLimit test
- Fix numberOfConnections call to be number of incommingConnections and not countPrunableConnections
- Changed everything to countIncomingConnections
- Applied pruning on:
  - OutboundIdleStateDuplex -> InboundStateDuplex;
  - OutboundStateDuplex -> DuplexState
  transitions
- Tweaked DemoteToColdLocal PruneConnections constructor
- Changed prune connections code:
  - for OutboundIdleStateDuplex -> InboundStateDuplex transition, prune
    code is pretty much the same except we have to check for
    (numberOfConns + 1) -- See Summary
  - for OutboundStateDuplex -> DuplexState transition, prune code has to
    check for (numberOfConns + 1) and also forcefully be contained
    inside its toPrune Set -- See Summary
  - for DuplexState -> InboundStateDuplex transition, prune code has to
    take into account if the connection is contained in its toPrune Set.
    If so we shouldn't update the connection to the new state as we
    might go above hardlimit.
- Tweaked MultiNodeScriptPruning and fixed shrink function
- Fix acceptLoop to handle the race condition with runConnectionRateLimits.
  If after accept successfully returns we get above the hardlimit, then cancel the accepted connection
- Fixed classifyPruning function

Summary:

In order for us to never go above hard limit connections we need to make sure that connections that evolve via OutboundDupSt Ticking → InboundIdleSt Duplex  and via OutboundState Duplex -> DuplexState  to use 'numberOfConns + 1' because we want to know if we actually let those connection to evolve if we need to make room for them by pruning.

For OutboundState Duplex -> DuplexState we also need to include it on its own pruneSet, since this connection might be a Sim-open connection and we are above the hardlimit, we really need to prune this connection in order to preserve the hard limit.

Due to the inherent race condition between accept and runConnectionRateLimits in the acceptLoop, we need to, after successfully running accept, check if accepting that connection put us above the hard limit. If it does then we need to cancel the connection.
Added multinode_Sim_Pruning_HardLimit test
- Fix numberOfConnections call to be number of incommingConnections and not countPrunableConnections
- Changed everything to countIncomingConnections
- Applied pruning on:
  - OutboundIdleStateDuplex -> InboundStateDuplex;
  - OutboundStateDuplex -> DuplexState
  transitions
- Tweaked DemoteToColdLocal PruneConnections constructor
- Changed prune connections code:
  - for OutboundIdleStateDuplex -> InboundStateDuplex transition, prune
    code is pretty much the same except we have to check for
    (numberOfConns + 1) -- See Summary
  - for OutboundStateDuplex -> DuplexState transition, prune code has to
    check for (numberOfConns + 1) and also forcefully be contained
    inside its toPrune Set -- See Summary
  - for DuplexState -> InboundStateDuplex transition, prune code has to
    take into account if the connection is contained in its toPrune Set.
    If so we shouldn't update the connection to the new state as we
    might go above hardlimit.
- Tweaked MultiNodeScriptPruning and fixed shrink function
- Fix acceptLoop to handle the race condition with runConnectionRateLimits.
  If after accept successfully returns we get above the hardlimit, then cancel the accepted connection
- Fixed classifyPruning function

Summary:

In order for us to never go above hard limit connections we need to make sure that connections that evolve via OutboundDupSt Ticking → InboundIdleSt Duplex  and via OutboundState Duplex -> DuplexState  to use 'numberOfConns + 1' because we want to know if we actually let those connection to evolve if we need to make room for them by pruning.

For OutboundState Duplex -> DuplexState we also need to include it on its own pruneSet, since this connection might be a Sim-open connection and we are above the hardlimit, we really need to prune this connection in order to preserve the hard limit.

Due to the inherent race condition between accept and runConnectionRateLimits in the acceptLoop, we need to, after successfully running accept, check if accepting that connection put us above the hard limit. If it does then we need to cancel the connection.
Added Pruning multinode_Sim test
- Fixed Simulation/Network/Snocket.hs accept function:
  Accept should be careful when finding a connection in Established or
  HalfOpened state, acting accordingly: When in Established state, fail
  the accept call as in the other side, the connect call fell through;
  when in HalfOpened, do not successfully return nor fail, but rather
  just take a new connection from the TBQueue.

  (This should be catched with more thorough Socket tests, see issue #3289)

- multinode_Sim tests refactor
Split `Collateral.SelectionParams` into `Selection{Constraints,Params}`.
This allows the `CoinSelection.Collateral` module to have an API that is
consistent with that of `CoinSelection` and `CoinSelection.Balance`, where:

 -  Selection constraints are common to all selections in a given era,
    and are determined by the protocol parameters.

 -  Selection parameters are specific to a particular selection, and are
    not determined by the protocol parameters.