Add methods to set invoice features in Features objects.

[valentinewallace]

I was struggling to get the Vec<u5> from lightning-invoice into an our-features-compatible Vec<u8>. This was much easier. Lmk if it makes sense.

[codecov]

Codecov Report

Merging #836 (e0c8ec5) into main (52edab7) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #836      +/-   ##
==========================================
+ Coverage   90.67%   90.68%   +0.01%     
==========================================
  Files          50       50              
  Lines       26828    26843      +15     
==========================================
+ Hits        24326    24343      +17     
+ Misses       2502     2500       -2     

Impacted Files	Coverage Δ
lightning/src/ln/features.rs	98.91% <100.00%> (+0.06%)	⬆️
lightning/src/ln/functional_tests.rs	97.10% <0.00%> (+0.03%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 52edab7...e0c8ec5. Read the comment docs.

[jkczyz]

I don't have a problem with this approach. @TheBlueMatt Any reason not to expose these?

[TheBlueMatt]

Hmm, our features historically have always been "don't export the manipulation bits, just allows creation via known or empty. I'm open to changing it, though it would be nice to do something more full-featured than piecemeal.

[jkczyz]

Hmm, our features historically have always been "don't export the manipulation bits, just allows creation via known or empty. I'm open to changing it, though it would be nice to do something more full-featured than piecemeal.

I tend to like a fluent-style API for this (consuming rather than mutating) similar to what I defined in a test:

https://github.com/rust-bitcoin/rust-lightning/blob/ad09a2f00413b50481975a08aa1315f8ca57291b/lightning/src/ln/features.rs#L673

[TheBlueMatt]

I tend to like a fluent-style API for this (consuming rather than mutating) similar to what I defined in a test:

Yea, definitely makes for cleaner rust code. I need to figure out how to properly map such things in the bindings, though, presumably via a constructor that takes a parameter for each possible function call. Gonna be hard with lightning-invoice. If it makes sense, would be nice to avoid it for a bit longer, but it may need to happen eventually anyway.

[valentinewallace]

Wtf. Why does this keep closing.

Edit: oh my changes mysteriously vanished.. fixing

[jkczyz]

It kinda sucks that we have to pass separate names for these. Especially considering we'd have to pass two more if we want to be consistent and define the existing supports_ and requires_ predicates using macros, too. Not sure if there is a better solution, though.

[TheBlueMatt]

I think technically you could do a procedural macro for this, but I don't know how to use them and I don't really want to find out.