[anchor commitment] Make the anchor commitment type spec compliant

[halseth]

This PR makes the necessary changes to the anchor commitment type to make it compliant with the final spec version as defined in lightning/bolts#688

There are two changes needed:

1. We set the feature bit to 20/21. This means that we now require this bit to be advertised to signal anchor support. The old bit will be ignored by new nodes.
2. The anchor amounts are given back to the initiator in a coop close scenario. This means that existing nodes having anchor channels will disagree on the final coop close fee if only one of the channel parties update. However if both update closing proceeds as normal. In the worst case force closing works as before.
3. Anchors are no longer experimental.

NOTE: Watchtowers are still not supported for anchor commitment types, and anchor support is not advertised by default but must be enabled through the --protocol.anchors option.

[cfromknecht]

first pass looks good

[cfromknecht]

possible underflow, here and below

[halseth]

Pre-existing, but I think it is safe to add the extra check: ca22db6

[cfromknecht]

can be simplified with +=

[joostjager]

maybe coopCloseFee + commitFee + anchorValue can be extracted to prevent a future bug where only one is updated

[halseth]

Extracted into initiatorDelta: a8ec11a

[cfromknecht]

preexisting: help message is a little misleading. it will work with watchtowers, but state updates for anchor channels won't be backed up. this should change before 0.12 though with anchor tower support in the works

[halseth]

Updated: 83fe313

[joostjager]

LGTM. Tested on regtest and inspected coop close tx. Anchor value is indeed added back to the initiator balance. Two questions:

• Did you (manually) test coop closing an old-format anchor channel?
• Is the itest coop closing with anchors anywhere?

[joostjager]

maybe coopCloseFee + commitFee + anchorValue can be extracted to prevent a future bug where only one is updated

[halseth]

• Did you (manually) test coop closing an old-format anchor channel?

Do you mean one node running the updated code, one node running the old code? If yes, then I tried this in one of the integration tests, and closing expectedly failed.

• Is the itest coop closing with anchors anywhere?

Yes, most tests using anchors are closing the channel at the end, most notably the basic funding flow test. Checks all combinations of channel types.

[cfromknecht]

@halseth looks good, can squash now

[joostjager]

Make clear in a comment that this is a sanity check and not supposed to be hit?

[halseth]

Done

[cfromknecht]

narrator: it was hit

[halseth]

Squashed and rebased. Removed the commit making anchors non-experimental as discussed, such that they are still behind a build tag.

[cfromknecht]

@halseth appears related to newly added underflow check

--- FAIL: TestCooperativeCloseDustAdherence (0.03s)
    channel_test.go:2291: unable to close channel: initiator cannot afford proposed coop close fee

[halseth]

@halseth appears related to newly added underflow check

--- FAIL: TestCooperativeCloseDustAdherence (0.03s)
    channel_test.go:2291: unable to close channel: initiator cannot afford proposed coop close fee

Fixed!

[cfromknecht]

lnwallet/channel_test.go:2285:5: `Attemtping` is a misspelling of `Attempting` (misspell)
	// Attemtping to close with this fee now should fails, since Alice

[halseth]

@cfromknecht Should be good now.

[cfromknecht]

LGTM 🤓