Parsing with invoices using feature bit above 63 overflows

[bjarnemagnussen]

Currently e.g. Acinq is generating invoices in their Phoenix wallet that advertises with a placeholder feature bit 149 for trampoline support.

Parsing a Bolt11 invoice with this feature bit set will overflow in the Bolt11PaymentRequest.FeatureBits field, as it makes use of an enum that does not support that many distinct features. In fact due to the overflow it will set the (unrelated) feature bit 21 instead.

See here for a live-demo of the overflow where a Bolt11 invoice containing feature bit 149 will overflow to set feature bit 21.

One possible solution that does not break back-wards compatibility could be to limit the existing FeatureBits field to only the first 62 feature bits ensuring it does not overflow, and then add a RawFeatureBits field that uses a BitArray as backing allowing for more distinct feature bits.

I can work on a PR for this but just want to make sure that the general approach has a chance of being accepted by the maintainers.

[dennisreimann]

The proposed concept sounds good to me and we would gladly invite that as a pull request. 👍