Fix several build warnings.

- LICENSE: change from MIT to AGPL (.Kiss fork)
- Change package name suffix from .Core to .Kiss
(skipping native build)

This commit adds the following:

* getFundsFromForceClosingTransaction

This function takes an on-chain transaction which spends the channel
funds and tries to extract spendable utxos out of it. If successful, it
returns a TransactionBuilder with txins added for each spendable output
of the closing transaction and with the necessary keys and
BuilderExtension added. To recover funds from a broadcast commitment
transaction you just need to call this function, add outputs to the
returned TransactionBuilder to send the money where you want it to go,
then broadcast the transaction.

* CommitmentToLocalBuilderExtension

This is an NBitcoin BuilderExtension that tells TransactionBuilder how
to recognise and sign lightning commitment transaction to_local outputs.
getFundsFromForceClosingTransaction adds this extension to the
TransactionBuilder it returns if it's needed to sign the transaction.

* SeqConsumer

A computation expression which makes it easy to write code that consumes
a sequence one element at a time.

* OptionCE

A computation expression for creation options. Similar to the result
computation expression.

This NBitcoin issue: MetacoSA/NBitcoin#931
somehow still hasn't been fixed properly (our geewallet CI still encounters it,
surprisingly).

So let's reapply the workaround[1] that we had removed[2].

[1] joemphilips@d813a97
[2] joemphilips@256893c

These tests are failing randomly and macaroons aren't used by geewallet
anyway. So exclude them from CI.

Move/rename ChannelError.feeRateMismatch to FeeRatePerKw.MismatchRatio.

This function is useful outside of DotNetLightning, so we now export it
so that library consumers can use it.

Prior to this commit, apply an update_fee message would cause DNL to
validate the message but not actually apply it to its commitments.

It now updates its commitments as it should.

These states don't have commitments, only exist before the existence of
a channel is confirmed, don't need to be saved in a wallet, and can only
handle one specific ChannelCommand each.

As such, it doesn't make much sense to have them be part of
ChannelState. They can instead be seperate types which exist prior to the
creation of a channel and which have specialized methods for performing
the single operation which they can handle.

They don't need to anymore since all channel states have a channel id
and commitments.

This field is unused.

These settings are only used for choosing whether to accept open/accept
channel messages. They don't need to be stored in the channel.

Previously the local shutdown script was stored in two places in the
channel and also provided as an argument when initiating a shutdown.
This made it possible to send invalid shutdown messages if the shutdown
scripts provided by the user at different times were different. Also,
shutdown scripts have to be in certain forms, but the only place that
they were validated was when initiating a shutdown.

There's now a ShutdownScriptPubKey type which wraps a Script and
enforces that the script is a valid shutdown script. This is used
throughout the code for all scripts which are shutdown scripts, which
forces us to check their validity at all required points.

The DefaultFinalScriptPubKey field has been removed from LocalParams so
that we only store the local shutdown script in (at most) one place in
the channel datastructure. This shutdown script is an Option, and can be
None in the case that we didn't specify a shutdown script to give to the
remote peer when creating the channel. As such as we still pass a
shutdown script as an argument when closing a channel but we also check
that it matches the recorded shutdown script that we previously gave the
remote peer in the case that it's Some.

The types WaitForOpenChannelData, WaitForFundingInternalData, and
WaitForRemotePublishFutureCommitmentData were defined but not used at
all. They have been removed.

Remove long lines and excessive rightward drift. Add types to function
parameters and return types. This makes the code more readable and
consistent.

Since all ChannelState variants have a Commitments field, this field can
be factored out into the Channel object.

Also, remove the ChannelId field from the ChannelState variants since it
is duplicated inside Commitments.

Commitments already stores the funding tx outpoint, which is what the
channel id is dervied from. So we can de-duplicate state by deriving the
channel id when needed.

The types WaitForFundingSignedData, WaitForFundingCreatedData,
ChannelWaitingForAcceptChannel and InputInit{Funder,Fundee} are only
used in a single place each as part of larger structures that they can
be inlined into. This will make it easy to refactor the channel types in
a subsequent commit.

Remove ChannelWaitingForAcceptChannel.LastSent,
ChannelWaitingForFundingTx.LastSent and
ChannelWaitingForFundingCreated.LastSent. All the fields of these values
are duplicated elsewhere in the channel state.

This is another bit of duplicated state which is unused.

LocalParams.ChannelPubKeys is duplicated state since our pub keys are
derived from our private keys. RemoteParams.ChannelPubKeys can be moved
into commitments to bring the two *Params types inline with each other.

This field was unused.

This data is already available in the commitments in the commitment
spec.

It's not clear if this field is supposed to be different from
InitFeeRatePerKw (eg. to support using a different fee rate for the
funding tx and for the channel). But as it is they were both being used
as the fee rate for commmitment specs so it would have been an error to
set them differently. As such I've merged this field with
InitFeeRatePerKw. Another field could be added later to support using a
different fee rate for the funding tx, but it'll need to be implemented
correctly.

This field is pointless and wasn't being used.

It's not at all clear what this field was intended for. If it's meant to
indicate the the funding tx is buried then we should never be in a
`Normal` state with `Buried = false` since being in a `Normal` state is
meant to indicate that funding has been locked.

At any rate, the field was never being read so I've removed it.

If we have their funding locked msg then we're not waiting for their
funding locked message. So this field makes no sense. Also it wasn't
being used, so it's been taken out.

These events are always emitted at the same time and so don't need to be
two separate events. Also, remove the HaveWeSentFundingLocked field from
WaitForFundingLockedData because we have always sent funding locked when
we enter that state.

This field was unused.

This field was unused.

This field was unused.

This type was unused.

This field lived in Commitments but we don't always have this
information available when we have a Commitments object, so it was being
filled with dummy data.

We only obtain the remote's next per commitment point when we receive
funding_locked. As such, this field should only be present in states
that are subsequent to funding_locked.

This type only had field left of type RemoteCommit. So it can just be
replaced with RemoteCommit.

We don't need to store a FundingLockedMsg here. Just the
PerCommitmentPoint that it contains.

This field is unused.

This field was unused.

Rather than having separate `ChannelState`s for waiting for funding
confirmed/locked we can merge these into the Normal state. The Normal
state's ShortChannelId and RemoteNextCommitInfo have been turned into
options where a value of `None` indicates that funding is not confirmed
or that the peer has not sent funding_locked respectively.

The advantages of this are:
  (a) It simplifies the code by removing two more channel states.
  (b) it allows us to handle channel shutdown before funding has been
      locked. This is required by the lightning spec but, prior to this
      change, attempting to apply a remote's `shutdown` message before
      the funding is confirmed and locked would have crashed DNL.
  (c) It's a step towards refactoring the channel type into two layers -
      one which is saved to the wallet and persisted across reconnects,
      and another which is discarded when the connection is dropped.

…ngHTLCs

This event doesn't actually change the commitments. It's constructed
using the channel's current commmitments and then replaces the channel's
commitments when applied. So the channel's commitments are left
unchanged, and the field is redundant.

This state is redundant. The `Normal` state already has `Option` fields to
indicate whether we have sent and recieved shutdown messages but, as is,
never sets both of them to `Some` at once and instead transitions to the
Shutdown state when the second one would be set to `Some`. We can
instead just remove this state and have two `Some` values be the
indicator that we are shutting down.

This removes a lot of code-duplication between how messages and events
were handled between the two states.

These values were being thrown away and weren't being cross-checked
against the script we receive in their shutdown message. We now store
them in the channel state and raise an error if the peer sends us a
different message in their shutdown.

We don't need to store the original messages that we sent/recieved, just
the shutdown scripts within them.

The local/remote shutdown scripts were being held in two places in the
channel data structure. We now hold them in a single place and structure
the types so that we always have a side's shutdown script when they have
entered shutdown.

These fields were completely unused.

This field was a List<List<ClosingTxProposed>>, however the inner List
only ever contained zero or one elements. As such, it makes more sense
to make it an Option.

This field had type List<Option<ClosingTxPerformed>>, however a None
could only appear as the final element in this list where it was
ignored anyway. The program logic is identical if we simply make this
field a List<ClosingTxPerformed> and never insert a None at the end of
the list.

This field was set but never read.

Remove ClosingTxProposed type and change the ClosingTxProposed field of
NegotiatingData to just be a list of proposed fees instead.

We don't need to store copies of the closing_signed messages and nor the
closing transactions that we've proposed. We don't currently use them
and we can always re-create them on demand anyway.

The lightning spec requires us to fail a channel if the remote peer
proposes a closing fee which is not strictly between the previous fees
proposed by both sides. This was not being enforced.

This commit adds a field to NegotiatingData which tracks this value so
that a protocol violation of this sort can be caught.

This type was a field of every variant of ChannelState. So rather than
keeping it in ChannelState it can be moved up into Channel.

Also remove the Opt suffix from the field name.

The ShortChannelId isn't tied to being in a non-closing state and we may
need to access/modify it when we are in a negotiating state (for
instance, if the channel is shutdown before funding gets locked).
So move it up into Channel.

Also remove the Opt suffix from the field name.

This field was unused. Also the txid of the remote commitment can be
derived from the commitment spec which is held next to it in
RemoteCommit.

All this function did is ignore its arguments and return
MutualClosePerformed, so we can just inline that instead.

This function was unfinished and unused.

Rather than storing the channel flags in a uint8 and accessing the flags
through bit positions, use a structured type to hold the flags.

This makes the code clearer and less bug-prone, and also hightlights
that the announce_channel flag is duplicated in two places in the
Channel structure.

Re-duplicate the local/remote ShutdownScriptPubKey fields since shutdown
scripts sent during channel initialization need to be remembered for the
lifetime of the channel but shutdown scripts sent during shutdown should
be forgotten if the connection is broken before shutdown is complete.

Factor the negotiating data out into the Channel type and remove
ChannelState. The last other remaining state (NormalState) was now
pointless since we store the static shutdown scripts in Channel so that
they can be remembered regardless of what state we're in. The
NegotiatingData field of Channel indicates that we are in shutdown if
both peers have shared shutdown messages.

This type represents all channel configuration which is established
during the handshake and remains unchanged through the lifetime of the
channel.

The following fields are moved into this type: AnounceChannel,
RemoteNodeId, Network, FundingTxMinimumDepth, the shutdown scripts,
IsFunder, FundingScriptCoin, {Local,Remote}Params, and
RemoteChannelPubKeys. In doing so, we reduce the number of fields in
Commitments and the channel types.

Also, in CommitmentsModule, rather than passing around all the fields
individually pass the entire StaticChannelConfig object.

Remove the channelPrivKeys argument from the NewInbound and NewOutbound
methods on Channel. This argument is redundant since it is computed from
the NodeMasterKey that we pass to these methods.

Also de-tuple the function arguments and remove a unnecessary level of
indentation.

Change the CreateChannelReestablish operation into a method.

Also make the RemoteNextCommitInfoIfFundingLocked{,Normal} helper
functions into methods.

These are no longer used since we now do everything through methods on
Channel.

This field was unused.

This was mis-named (it's the temporary channel id, not a "temporary
failure") and also unused (we don't need the temporary channel id
anymore at this point).

Fields in this message were duplicated elsewhere in this type.

Commitment and htlc transactions only have a single input, so the
WhichInput field is always set to zero and is meaningless.

There may be both an incoming and an outgoing htlc for any given htlc
id, so we can't store both incoming and outgoing htlcs in the same map
under the same id.

Separating these into two maps also makes the code a bit less strange
since we no longer have to keep filtering the map for the htlc-direction
that we want.

This module defined the following interfaces:

    type IState = interface end
    type IStateData = interface end
    type ICommand = interface end
    type IEvent = interface end

These were not used in the code anywhere

This is needed in geewallet for getting the spendable balance of channel
when we only have the components of a Channel object but not the Channel
object itself.

This method can be moved onto SavedChannelState when the necessary
fields remaining in Channel/Commitments are moved there.

When SpendableBalance is called when the funding is not yet locked,
report the full channel balance rather than crashing.

Previously SignCommitment would return None instead of a
CommitmentSignedMsg if either:
  (a) There were not updates to sign or
  (b) A revoke-and-ack for a previous commitment was not yet received

Since these cases both indicate a misuse of the API they have been
changed to errors.