…frames

Since we want to use multiple former per-hop-payloads as a single
payload, we want to differentiate the notion of a frame from a
payload, since the latter can be now be made up of multiple frames.

Signed-off-by: Christian Decker <@cdecker>

HopPayload represents the raw, unparsed payload, from which the
HopData can be parsed. The sphinx code internally only handles
HopPayload, and the `HopData()` method can be used to parse and return
the HopData. This completes the transition to HopPayload.

Signed-off-by: Christian Decker <decker.christian@gmail.com>

This is the central commit in this whole series, it modifies the
right- and left- shifts to account for multi-frame payloads and it
modifies the filler generation code to generate multi-frame fillers if
the payload requires it.

Signed-off-by: Christian Decker <decker.christian@gmail.com>

This is a simple test that create a 5 hop onion, and the third hop
gets a payload that spans 2 frames.

Signed-off-by: Christian Decker <decker.christian@gmail.com>

This should make testing a lot easier, since we can just have a bunch of these
sitting in the repo and test them.

Signed-off-by: Christian Decker <decker.christian@gmail.com>

In this commit, we move the HopData struct back into path.go. Along the
way, we remove its old HMAC field (since it's now in the hop payload),
and also restore its Decode method for later use.

In this commit, we add a new constructor to abstract away the details of
the hop payload framing from the caller. This new function accepts the
hop data, as well as optional EOB bytes. We'll then map these two pieces
of data into a single hop payload by appending the EOB bytes to the
serialized hop data.

Rather than mutate the underlying realm byte, we'll now expose two
methods to the caller: one for the "external" realm, and one of the
realm that we'll encode in the payload.

In this commit, we remove the HopData field from the OnionHop struct as
it's no longer needed since we can obtain the HopData via the HopData()
method of the HopPayload struct. Additinoally, we also now return the
set of unused payload bytes after the HopData encoding, we call these
the EOB or extra onion blobs.

With this distinction we now provide the caller of ProcessOnionPacket
with the forwarding instructions, then the left over EOB bytes. These
EOB bytes will then be interpreted using a TLV format or any other
arbitrary framing system.

In this commit, we make the jump from the prior fixed sized frame
payloads, to the latest variable sized format. The main change is that
now we no longer need to pack all the payloads into a fixed frame size,
adding padding. Instead, for the new TLV format, we'll now use a var-int
to signal the length of the payload.

In the process, we lift the Realm field from the HopPayload struct into
the HopData struct. We do this as the new TLV payload has no realm
field, and it's instead used to signal the existence of the legacy
payload format.

We no longer have the concept of frames, so the old test no longer applies.