routing by packet lookup

This PR changes the way packets get their routing determined, for the purpose of having more freedom in how we store SessionKey Filters.

The when of packets

The first time a packet is see, we take a lock on the phash and start finding if it's routable. Any packets that come in during that time will queue themselves. Once the routing is figured out, the initial packet, and all the queued packets are routed, and the routing information is put into ETS. Any packet coming along after routing has been determined will immediately retrieve it's routes.

Multi-buy is always checked.

But there's a lot of changes to SKF storage...

The last_used timestamp for an SKF is removed. Worst case scenario is the applicable SKF is at the end of an ETS table, but that lookup is only done one time per hash.

This means we can keep SKF unique by session_key, and delete in constant time.

Other things of note

We no longer assume that if 2 routes have a valid SKF, the latest one wins. Now, both routes will be routed to.
There's a cleanup job for phash routing. I based it loosely off of packet-purchaser unique packet hash counter.
- It crawls the table more often than the removal window to keep the table from getting bigger than can be traversed in a single window.
- packet-purchaser was doing this while being a default router.
There as a multi-buy test that was relying on a race condition.
- There was a max_copies of 3, and we were simulating 2 servers for every request. The test asserted that 3 requests were sent, but that could only happen if request 2 and 3 were sent at the same time.
- It's been updated to wait until multi-buy has received more than max_copies worth of function calls, and makes sure it's sent less than the expected requests.

Number of SKfs	Worst case time
100	4ms
1,000	27ms
10,000	217ms
20,000	431ms
50,000	1027 ms
100,000	2048ms

helium / helium-packet-router