the old way fired off a new (very short lived) thread for each message received, and if two happened really really quickly, they'd both lock on the mutex and the order would be undefined
this avoids that. thanks to oOo et al for pestering me and sending in logs :)
* drop the outbound message as soon as it expires rather than transferring an expired message
* drop hard any outbound message that takes us over 5 seconds to process (if we have a 5s message processing time, we do no one any good)
* don't try to resend (only useful when dealing with multiple transports - aka insufficiently tested code)
* don't republish netDb messages as often
* reduced the number of tags passed when garlic routing a tunnelCreate
* catch timeout on a tunnel message quicker
* give a tunnel message a new messageId per hop
* added some more infrastructure for per-hop tunnelId
* removed SourceRouteBlock & SourceRouteReplyMessage, as they're a redundant concept
that 1) takes up bandwidth 2) takes up CPU 3) smell funny.
now the TunnelCreateMessage includes a replyTag, replyKey, replyTunnel, and
replyGateway that they garlic encrypt their ACK/NACK through and with.
* tunnelCreateMessage doesn't need a seperate ACK - either we get a
TunnelCreateStatusMessage back or we don't.
* message structure mods for unique tunnel ID per hop (though currently all hops have
the same tunnel ID)
(making a searchReply message ~100 bytes, down from ~30KB, and the lookup message ~64 bytes, down from ~10KB)
* when we get the netDb searchReply or lookup message referencing someone we don't know,
we fire off a lookup for them
* reduced some excessive padding
* dropped the DbSearchReplyMessageHandler, since it shouldn't be used (all search replies
should be handled by a MessageSelector built by the original search message)
* removed some oddball constructors from the SendMessageDirectJob and SendTunnelMessageJob (always must specify a timeout)
* refactored SendTunnelMessageJob main handler method into smaller logical methods
cleaned up rebuild / verification process so that the select*TunnelIds will always return what is necessary
for the moment, don't automatically kill all tunnels of a peer who fails just once (they can recover)
logging
if/when the property "timestamper.enabled" is set, the timestamper will query the sntp server(s) and update the clock accordingly
if/when it is not set (or set to something other than "true"), it will pause with its standard delay before checking again
in addition, it has a guard to help running the timestamper multiple times in the same JVM
new piece of data exposed and maintained is a list of router contexts - shown as a singleton off RouterContext - allowing an app in the same JVM to find the routers (and chose between which one they want)
