Batching preprocessor that will briefly delay the sending of a message
if it doesn't fill up a full tunnel message, in which case it queues up
an additional flush task.
Allocate data out of a large buffer of data, rather than the PRNG's
(likely) small buffer to reduce the frequency of prng recalcs (though
the recalcs are now more time consuming).
Receive the build message at a certain hop, decrypt its encrypted record,
read the enclosed tunnel request, decide how to reply, write the reply,
encrypt the reply record, and return a TunnelBuildMessage to forward on to
the next hop
Simple test to create an encrypted TunnelBuildMessage, decrypt its layers (as it would be
during transmission), inject replies, then handle the TunnelBuildReplyMessage (unwrapping
the reply encryption and reading the replies).
If the client's config specifies shouldBundleReplyInfo=true, messages sent from
that client to any peers will probabalistically include the sending destination's
current LeaseSet (allowing the recipient to reply without having to do a full
netDb lookup).