[feature]/tapchannels: carve out extensibility vectors for tap channels

[Roasbeef]

Is your feature request related to a problem? Please describe.

As the protocol evolves, we'll need to be able to also evolve the asset channels format and operations.

One example is the NoopAdd HTLC we've ideated, which gives us a solution to always having to push over a sat amt for a payment.

Without any sort of versioning or feature bit scheme on the channel level, we won't be smoothly introduce new features to channels. In that realm, the only way to "upgrade" is to close out and open channels again, which isn't desirable for end users.

Describe the solution you'd like

We have quite a few extension levers at our finger tips:

• The channel_type feature bit:
  • This is sent over in the open_channel message. If we don't know some extra bit (maybe it's a slightly diff format), then we can send a reject message over.
  • We can thread this down through the into the FundingController to decide if we support that channel type or not.
• The set of feature bits lnd advertises:
  • This can be used to filter out nodes in the graph that support a given feature.
  • Right now this value is static in lnd, but we can update it via the UpdateNodeAnnouncement RPC.
  • This'll let us start to advertise new variants of the channel format. It will be up to tapd to try to send over the best feature bit combo for compat.
• The channel_reestablish message:
  • This has space for extra TLVs. Today splicing, and also taproot channels use up this space.
  • We can use this to detect behavioral changes to an existing channel.
  • We likely shouldn't take this path often, as it is effectively an in-place update, so it should be reserved mainly for bug fixes.

Of the above, the only area we lack hooks for is putting/reading extra data in the chan reest message.

The the noop HTLC feature, I think we can just add a new feature bit, then check to see if the peer supports it before we use it.

The chan reest message is also an option here.

If we make any explicit breaking changes such as changing the scripts, or the way we decide things like who the anchor will be, then we'd bump the channel_type feature bit. For this, we'll need some versioning within the TAP specific channel code.

[Roasbeef]

We can also use the init message for this. There're some feature bits that are only sent in init, and not also node_announcement.