Include tests for requires_unknown_bits and supports_unknown_bits when
an unknown even bit, odd bit, or neither is set. Refactor bit clearing
such that tests and production code share the same code path. Fix a
potential spec incompatibility (currently only exposed in testing code)
where trailing zero bytes are not removed after a bit is cleared.
Converting from InitFeatures to other Features is accomplished using
Features::with_known_relevant_init_flags. Define a more general
to_context method which converts from Features of one Context to
another.
Additionally, ensure the source context only has known flags before
selecting flags for the target context.
Features for a given context are duplicated throughout the features
module. Use a macro for defining a Context and the applicable features
such that features only need to be defined for a Context in one place.
The Context provides bitmasks for selecting known and unknown feature
flags.
BOLT 1 and BOLT 9 refer to features as "known" if a peer understands
them. They also use the term "supported" to mean either optional or
required.
Update the features module to use similar terminology.
- Define contexts in terms of required and optional features rather than
just supported features
- Define known features as those that are optional or required
- Rename supported() constructor to known()
For completeness, clear_optional_bit for each feature is now called
clear_bits and clears both optional and required bits.
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.
PeerManager determines whether the initial_routing_sync feature bit
should be set when sending Init messages to peers. Move this to the
Router as it is better able to determine if a full sync is needed.
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.
Accessing a struct through an std::syn::MutexGuard using implicit
dereferencing can confuse the borrow checker. This situation arises when
obtaining mutable references to more than one field of the struct, which
is normally allowed.
https://doc.rust-lang.org/nomicon/borrow-splitting.html
However, when using implicit dereferencing, a mutable reference to the
the entire struct is taken. Thus, attempting to access another field in
this manner will lead to a compilation error.
https://doc.rust-lang.org/error-index.html#E0499
A simple way to avoid this is to first obtain a mutable reference to the
struct using explicit dereferencing.
The Features::new() method is nonsense and doesn't describe what
features were being set - we introduce an empty() and supported()
constructors instead.
This change was made in the flat features BOLT PR, as if a channel
requires some unknown feature bits we should still rumor it, we just
shouldn't route through it.
This merges local and global features into one struct, which is
parameterized by where it appers. The parameterization restricts
which queries can be made and which features can be set, in line
with the latest BOLT 9.
Closes#427.
