Each feature is represented by two bits within Features' flags field.
Working with these flags requires bitwise operations, which can be error
prone. Rather than directly checking and manipulating bits, encapsulate
the bits within each feature trait and provide mechanisms for doing so.
This removes the need to comment on which features correspond to bitwise
expressions since the expressions use feature trait identifiers instead.
With this approach, byte literals and expressions can be evaluated at
compile time still. However, for these cases, knowing which byte within
the flags that a feature corresponds to still must be determined by the
implementor.
Remove the special case where initial_routing_sync has no even bit. Now,
it (bit 2) is considered known by the implementation.
The initial_routing_sync feature is set by peer_handler whenever a full
sync of the network graph is desired. It is not explicitly set when
creating features with InitFeatures::supported().
An upcoming refactor will change supported() to known(), which will
return all features known by the implementation. Thus, the
initial_routing_sync flag will need to be set by default. This commit
makes the behavior change ahead of the refactor.
The test_upfront_shutdown_script functional test clears this feature
flag. However, the method used to clear the flag is implemented by bit
toggling. Thus, if the flag is not set the method would actually set it.
Implement the method using bit clearing instead.
This makes Readable symmetric with Writeable and makes sense -
something which is Readable should be Readable for any stream which
implements std::io::Read, not only for a stream type it decides on.
This solves some lifetime-compatibility issues in trying to read()
from a LengthLimitingReader in arbitrary Readable impls.
This implements the new TLV variable-length encoding for onion hop
data, opting to send it if the RouteHop's node_features indicates
support. It also uses the new process_inline method in ChaCha20 to
optimize a few things (though it grows a new TODO for a
probably-important optimization).
This exposes the latest Init-context features in the ChannelDetails
passed to the Router during route calculation, which combines those
with the Node-context features tracked from node_announcements to
provide the latest Node-context features in RouteHop structs.
Fields are also added for Channel-context features, though those are
only partially used since no such features are defined today anyway.
These will be useful when determining whether to use new
TLV-formatted onion hop datas when generating onions for peers.
