When we start creating blinded paths to ourselves, we will want to be
able to pad the data for each hop so that the `encrypted_recipient_data`
for each hop is the same. We add a `PadBy` method that allows a caller
to add a certain number of bytes to the padding field. Note that adding
n bytes won't always mean that the encoded payload will increase by size
n since there will be overhead for the type and lenght fields for the new
TLV field. This will also be the case when the number of bytes added
results in a BigSize bucket jump for TLV length field. The
responsibility of ensuring that the final payloads are the same size is
left to the caller who may need to call PadBy iteratively to achieve the
goal. I decided to leave this to the caller since doing this at the
actual TLV level will be quite intrusive & I think it is uneccessary to
touch that code for this unique use case.
Add the PathID (tlv type 6) field to BlindedRouteData. This will be used
for the final hop of a blinded route. A new constructor is also added
for BlindedRouteData which can specifically be used for the final hop.
For the final hop in a blinded route, the SCID and RelayInfo fields will
_not_ be set. So these fields need to be converted to optional records.
The existing BlindedRouteData constructor is also renamed to
`NewNonFinalBlindedRouteData` in preparation for a
`NewFinalBlindedRouteData` constructor which will be used to construct
the blinded data for the final hop which will contain a much smaller set
of data. The SCID and RelayInfo parameters of the constructor are left
as non-pointers in order to force the caller to set them in the case
that the constructor is called for non-final nodes. The other option
would be to create a single constructor where all parameters are
optional but I think this makes it easier for the caller to make a
mistake.
This commit adds encoding and decoding for blinded route data blobs.
TLV fields such as path_id (which are only used for the final hop)
are omitted to minimize the change size.
