sdk/state: new state StateClosedWithOutdatedState

[acharb]

WHAT
if the seq num gets moved to a seq corresponding to an early close transaction (close transaction other than the latestAuthorized one) then the channel state will return a new state StateClosedWithOutdatedState, and close the channel from ingesting new transactions

WHY
currently the channel stays on StateClosingWithOutdatedState if we've ingested an earlier closeTx. The channel state should return closed since that's what occurred on the network. Also we should block new transactions from being ingested so that EI submitting new transactions does not interfere with the channel state.

closes #308

[leighmcculloch]

Logic looks great 👍🏻. I think as a follow up this functionality could be refactored inside of txbuild, that would continue to keep logic about sequence numbers in that package.

[leighmcculloch]

Could you add some tests that demonstrate even and odd starting sequences, and then both tx types? 😄

[acharb]

that's a good idea c1426f1

writing the test made me think that we should add a TransactionTypeOpen (if they're the same)

also there's 1 unique case of the startingSequence + 1, which isn't a transaction type. Maybe we should add a type for that as well (it would be something like TransactionTypeNone)

[acharb]

added them here
d5e1329

[leighmcculloch]

I wonder if we can focus on the transaction types being for close agreements then, because I don't think we get much bang out of adding other types.

I wouldn't worry about adding the none case either, we don't sign txs with those sequence numbers. I'd just panic in that case, it's code that should never be hit.

[acharb]

added the panic 0b1d1df

imo I think the TransactionTypeFormation makes sense, isn't used now but may save a bug down the line if someone means to get the formation tx seq and not the declaration tx seq 🤷

up to you though I can remove if it's added code for no reason

edit: "if they meant to be referring to a formation tx and not a declaration tx" I mean