Reject new static remote key channels in 0.22 #11216

#11212 stops lnd from opening or accepting new channels using the legacy
commitment type. It deliberately left the static remote key type alone. This
issue tracks refusing that one too in 0.22, so that new channels must use
option_anchors_zero_fee_htlc_tx or later.

Why it was not done in #11212

That PR is a backport to 0.21 and 0.20. Refusing the static remote key type
means refusing channels from any peer that does not support anchors, in both
directions, which is a compatibility break that does not belong in a patch
release. The type is also still spec-valid: it is what replaced legacy, and
its to_remote output is untweaked, so the recovery problem that motivated
#11195 does not apply to it. Removing it is deprecation housekeeping rather
than a fix, which makes a major release the right place for it.

Prerequisite

This is blocked on #11213. Anchors are off by default in the integration build
(lncfg/protocol_integration.go), so a node started without
--protocol.anchors can only negotiate the static remote key type, and every
test that pairs such a node with an anchors one stops being able to agree on a
commitment type.

I measured this by implementing the change and running CI. Seven tests fail,
in two groups.

A default node peering with an anchors node:

• batch_channel_funding, where bob is created with nil args while
  alice runs with --protocol.anchors
• psbt_funding_simple_taproot and psbt_external_funding_simple_taproot,
  where runPsbtChanFundingWithNodes creates alice with nil args while
  carol runs taproot
• zero_conf-channel_policy_update_public and its zero-conf variant, where
  eve is created with nil args
• option_scid_alias/private_chan-type, same shape with bob

An anchors node asking for the type explicitly:

• channel_fundmax_error, where runFundMaxTestCase defaults commitType to
  STATIC_REMOTE_KEY while testChannelFundMaxError starts both nodes with
  --protocol.anchors. Switching that default to ANCHORS moves the fee
  arithmetic, so the hardcoded expectations such as "output amount(-0.00000435 BTC) after subtracting fees(0.00002435 BTC)" have to be
  recomputed.

testZeroConfChannelOpen and testOptionScidUpgrade have the same shape as
the first group but did not fail in that run, which I could not explain. Worth
checking when the work is picked up.

What the change involves

Refuse the type in explicitNegotiateCommitmentType, and stop
selectDefaultChannelType from falling back to it once the peer cannot do
anchors, failing the flow instead of quietly downgrading. Reject
commitment_type STATIC_REMOTE_KEY in OpenChannel, and drop the
tweakless value from lncli openchannel --channel_type.

protocol.no-anchors has to be deprecated and made a no-op at the same time,
otherwise a node that turns anchors off is left unable to open any channel at
all.

The LEGACY and STATIC_REMOTE_KEY enum values themselves have to stay.
CommitmentType is also the reporting type for ListChannels,
ClosedChannels, PendingChannels and the channel acceptor, and channels that
already use those types still report them.

Existing channels of either type must keep working. Dropping the code that
drives them is a separate step, and should come after this one.

Advertising it

Worth deciding separately whether to flip option_anchors_zero_fee_htlc_tx
from optional (bit 23) to required (bit 22), the way option_static_remotekey
(bit 12) was made required when legacy was first phased out. It is a
connectivity-level statement: peers we still hold non-anchor channels with have
to keep connecting so those channels can be operated and closed, so it cannot
happen until those are gone.