Fix "very close" message when configured for all routers

it's already called from IMF

Log tweaks

WIP, not fully tested
Don't try to rebuild IPv4 address when IPv4 disabled
Don't bid on a peer if marked unreachable
Fail outbound immediately if no valid introducers
Reduce IPv6 too-close length check from 8 bytes to 4
Log tweaks

Ratchet: Don't schedule a reply to a LS with zero leases

Enable ipv6 check in locked_rebuild()
Change locked_needsRebuild() to return codes for ipv4/v6
Change locked_needsRebuild() for introducers so it only
returns true if more are available
Change rebuildExternalAddress() so we can do a rebuild of ipv6 without an IP
Only call rebuildIfNecessary() on peer drop if it could have been an introducer
Fix check in pickInbound() for support of AliceIP field
Log tweaks

Reverse cache wasn't regenerated at midnight,
so decryption would fail after the first routing key change.
We had the rollover() method but it wasn't called.

WIP
Offer intro key for IPv6
Pick introducers for IPv6
Publish address with IPv6 introducers
Reduce churn of selected introducers
Only adjust transport bid if they publish C cap
Log tweaks

state was right but published address wasn't updated because looking
in wrong place for saved ipv6 address

reported by zlatinb
patch from jogger

We don't want to match on "46"

WIP, see proposal 157.
Will not take effect until we actually send ITBMs.
Tested with regular VTBMs.

Part 1:
Change bandwidth estimate to exponential moving average
(Similar to Westwood+ Simple Bandwidth Estimator in streaming)
instead of 40 ms bucket.
Also use it for tunnel.participatingBandwidthOut stat.
Remove linear moving average code previously used for stat
Reduce RED threshold from 120% to 95% of limit

Part 2:
Fix the other part of RED which is the dropping calculation.
Previously, it simply used the bandwidth to start dropping if
it 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 77 ms and 333 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.
The 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.

There may be more tuning required, in particular to achieve the goal of "protecting" the UDP-Sender
queue and local client/router traffic by dropping more aggressively in RED.

This patch also improves the overhead estimate for outbound part. tunnel traffic at the OBEP.

Reviewed, tested, acked by zlatinb

for now, until implemented, see proposal 158

Set i2np.transportCaps=false to disable
Fix NTCP2 address with host and caps after state transition
Bump -7

Ensure IPv4/v6 peer tests are alternated
Reschedule peer test if result is UNKNOWN and a state transition is pending
Fix peer test last send time not being set in all cases

Do both writes and removes in the writer thread
As suggested by jogger http://zzz.i2p/topics/3082
log tweaks

Limit to ~5% < drop prob. < 100%

of logggung that was added during IPv6 development

Remove individual 1/2 enable config
Additional cleanup to follow