Reply pather per source

[juagargi]

The design of snet has one ReplyPather per SCION network object.
The snet.Conn that is obtained from Listen or Dial copies this reference to its own Conn object.
Additionally, there is only one Conn object at the server, where it just obtains it after Listen,
and simply reads all packets, obtaining the remote address as a return value of ReadFrom.

Since the HummReplyPather keeps state per client, it has to do its own bookkeeping.
For each Packet, a client ID is obtained using the IA, IP, and UDP port in said packet.
For each client ID, the HummReplyPather can keep a reverse reservation,
if one was sent via an E2E extension header.

If the reverse reservation contains no flyovers, it is not stored; it doesn't offer better guarantees to the server than the reverse path used to carry the packet from the client to the server in the first place.
Thus it's equivalent to just reverse the regular forward path received at the server.
It would remove a previous reverse reservation for that client ID if there were any,
to make the equivalence truly complete.

This PR adds extensive tests covering the following features of the HummReplyPather:

• Reverse reservation per client ID.
• Concurrent use by different goroutines.
• Cleanup of old (very expired) reverse reservations: avoids the memory consumption to grow forever.
• Reverse reservations without flyovers do nothing, or clean a previous reverse reservation, even if not expired.
• Cleanup happens at the SetState function: the only place where the storage grows, now also ensures it can shrink.
• Benchmark of the cost of cleaning up expired reservations: on a old desktop machine, between 200-800ns, depending on the number of existing reservations.

---

This change is 

[juagargi]

@juagargi reviewed 6 files and all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on juagargi).