Get rid of unneeded constructor.
We never need to use hardcoded reduced padding parameters during
negotiation cell construction. If we are using reduced padding
parameters, the layers which decide this have netparams to use.
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2826092
The network consensus parameters use (0,0) to mean "no padding"
(which is not the same as (0,0) means in a PADDING_NEGOTIATE cell).
Representing "no padding" this way is actually quite convoluted and
un-Rustic. Ensure that we convert (0,0) to None, and do the primary
logic in Option.
This gets rid of many Result(). Many parameters are renamed.
Test cases of the now-impossible branch are removed.
Deleting the match from padding_parameters will come in a moment.
I've split off that commit since it has much whitespace noise.
for now, change the error type to Void.
This is actually a general facility for inserting locally-generated
cells into the outgoing stream.
It doesn't seem to be possible to do this without adding an additional
condition check to the reactor, since we need to insert it into the
right place in the stream, giving it priority over data, and only
using it up if there was room in the output.
We don't engage this machinery yet, because nothing sets
special_outgoing.
Now all the information is plumbed to the right place, and we can
actually decide if we're sending padding.
Additionally, we conditionalise sending timing parameters on whether
padding is actually enabled, so in dormant mode we do not generate
updates (broadcast to all channels) just to reconfigure unused timing
parameters.
Change ChannelsParams::initial_update to compare fields with their
default values, and, if they're the same as the default, not to
include them in the returned update.
And if that update is then empty, return None.
The overall effect is to avoid the call to chan.reparameterize if
we're using the builtin default parameters, which is usual.
This arranges that the ChannelsParams we have retain, and which we
send to every newly created channel, actually has the right
parameters, even if they're not the default.
Now that the code that actually handles the netdir information can
cope with its lack, we can change the types of the various netdir
parameters and get rid of the foolish Bugs.
Now we actually honour the configuration variable.
However, when it is set to None, we lack proper handling. This will
be done bh turning None into 0,0 and then treating that as disabled.
There is a TODO for that.
Note that we *still* don't actually do or negotiate padding.
Move some logic out of reconfigure_general into what was
update_padding_parameters_from_netdir, and rename that function.
We're going to want to call this twice, shortly...
* Move out the PaddingParametersBuilder
* Have it handle missing netdir, though we currently always pass Ok
* Have it handle the error cases
It still ignores the config for now.
No overall functional change.
"git show -b" may be a useful way to review the changes in what
becomes "padding_parameters".
Now that we make an extract from the incoming NetDir, we can move the
padding parameters computation to after we take the lock.
This will be necessary for it to be able to depend on the config and
dormancy, records of which are protected by the chanmgr lock.
Ian Jackson
eta