Adds unique message ID's per context to bloom filter for safer replay protection.
The transport and client tunnel managers use a message ID in order to prevent
messages from being replayed. Prior to this checkin, the message ID queue used
the same IDs in clients and transports. If a message was sent to a transport
and a client with the same message ID, the message ID in one would cause a replay
to be detected in the other.
The result would be that the message reply would come back empty, creating a
point of evidence that a client and a transport were hosted on the same router.
However, there is no way from the attackers POV to determine with certainty that
the message was dropped because the message was replayed, making it very easy to
demonstrate a potential information leak using a known router and a known client,
but more difficult, to use to deanonymize a known client on an unknown router
(i.e. by trying routers from the local NetDB).
So what we have here is a situation where an attacker observing router behavior
can say that a message was dropped, and that they have reason to believe it is
because it contained an ID which was replayed. This constitutes a potential
information leak and is resolved by this checkin.
patch created by @obscuratus, tested, reviewed and checked in by @obscuratus and @idk
Write profiles to disk more often
Delete old profiles on disk more often
Reduce max age of profiles
Limit age of profiles read in at startup based on downtime
Limit total profiles read in at startup
Change loaded profiles from a Set to a List for efficiency
Log tweaks
Start expire job sooner if forced floodfill or downtime was short
Don't run refresh routers job if forced floodfill or downtime was short or vmcommsystem
Increase expire probability
Don't expire routers close to us just before midnight
Don't start expire leases job until 11 minutes after startup
Base probability out of 128 to reduce random usage
Consolidate now() calls
idk