WIP: Tunnels: Fix RED

This builds on and replaces MR !23 (closed) which fixed the bw calc used for RED by changing from a 40 ms bucket to an exponential moving average.

Here we fix the other part of RED which is the dropping calculation. Previously, it simply used the bw calc to start dropping if the bw was higher than a threshold. The drop percentage rose from 0 to 100%, linearly, based on how far the bandwidth was above the threshold. This was far, far from the RED paper.

Now, we follow the RED paper (see ref. in SyntheticREDQueue javadoc) to calculate an average queue size, using the exact same exponential moving average method used for bandwidth. Similar to CoDel, it also includes a count of how long the size is over the threshold, and increases the drop probability with the count. The unadjusted drop probability rises from 0 to 2% and then everything is dropped, as in the RED paper. The low and high thresholds are configured at 100 ms and 500 ms of queued data, respectively.

The queue is "synthetic" in that there's not actually a queue. It only calculates how big the queue would be if it were a real queue and were being emptied at exactly the target rate. All actual queueing is done downstream in the transports and in UDP-Sender.

The goals are, for an 80% default share, to do most of the part. traffic dropping here in RED, not downstream in UDP-Sender, while fully utilizing the configured share bandwidth. If the router goes into high message delay mode, that means we are not dropping enough in RED. Above 80% share this probably doesn't work as well.

Tested for a few days in the live net. There will probably be more tuning required, in particular to achieve the goal in live net of "protecting" the UDP-Sender queue and local client/router traffic by dropping more aggressively in RED.

WIP, not for merging, see !23 (closed) for additional comments.