Replace opt_anchors with ChannelTypeFeatures

[arik-so]

This is meant to replace #2321.

Fixes #1971.

[TheBlueMatt]

If we want to do this it has to happen in 116. Its by no means blocking 116, but tagging it as 116 so that we don't forget it just by accident. Will take a look when its non-draft/CI passes.

[codecov-commenter]

Codecov Report

Patch coverage: 95.02% and project coverage change: +0.82 🎉

Comparison is base (c5214c2) 90.28% compared to head (4b1f6ca) 91.11%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2361      +/-   ##
==========================================
+ Coverage   90.28%   91.11%   +0.82%     
==========================================
  Files         106      106              
  Lines       54323    63856    +9533     
  Branches    54323    63856    +9533     
==========================================
+ Hits        49047    58180    +9133     
- Misses       5276     5676     +400     

Impacted Files	Coverage Δ
lightning/src/ln/functional_test_utils.rs	89.29% <0.00%> (+2.00%)	⬆️
lightning/src/chain/package.rs	91.43% <88.99%> (+0.39%)	⬆️
lightning/src/chain/channelmonitor.rs	94.72% <95.45%> (-0.01%)	⬇️
lightning/src/ln/chan_utils.rs	94.51% <95.83%> (-0.34%)	⬇️
lightning/src/ln/channel.rs	92.49% <97.26%> (+2.67%)	⬆️
lightning/src/chain/onchaintx.rs	92.72% <100.00%> (-0.33%)	⬇️
lightning/src/events/bump_transaction.rs	41.55% <100.00%> (+0.76%)	⬆️
lightning/src/ln/features.rs	97.09% <100.00%> (+0.79%)	⬆️
lightning/src/ln/functional_tests.rs	99.13% <100.00%> (+0.90%)	⬆️
lightning/src/ln/monitor_tests.rs	98.05% <100.00%> (-0.23%)	⬇️
... and 2 more

... and 8 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[arik-so]

Hey @devrandom @ksedgwic, tagging you here to let you know that this is the serialization-changing PR I was talking about.

[wpaulino]

One minor drawback of using ChannelTypeFeatures instead of our own enum of supported channel types is that we'll store the full feature bit vector in all these different places. We're already up to 8 bytes per occurrence and it will only get bigger with new features, but not something we really need to worry about for now.

[TheBlueMatt]

This really needs to be more than one commit

[arik-so]

It's not really super splittable. I could modify the adjusted structs one by one, but the unit test modification onus would still be quite major for each commit, and it would make less sense than modifying all six structs at once.

The only thing that really lends itself to a split is the new feature and the new methods on channel type features.

[TheBlueMatt]

You could do some of the new utility functions separately. The biggest issue with it all being in the same commit isn't the raw diff size but more the various different changes across different files in the same commit. A commit that is super repetitive and just making the same change over and over again in a ton of places is fine, but limiting the number of different changes is good.

[arik-so]

I will squash the last two commits into the others later. Just wanna run cloud CI first before messing up too much at once.

[TheBlueMatt]

Needs rebase now that anchors handling bits landed.

[arik-so]

Yeah I can see that

[TheBlueMatt]

Fixes #1971

[TheBlueMatt]

You still have a commit which isn't word-wrapped at 60 chars.

[wpaulino]

Won't we break VLS if they're setting this and storing them?

[arik-so]

they did say they weren't, but we should confirm @devrandom @ksedgwic