I2NP:
Move some data structures away from ByteArray; offsets were always zero
  - New BuildRequestRecord constructors
  - BuildRequestRecord field becomes final byte[222]
  - IV becomes byte[16]
  - Build record becomes EncryptedBuildRecord
Remove extra copy in BuildRequestRecord.encryptRecord()
Remove unused BuildRequestRecord.readOurIdentityMatches()
propagate from branch 'i2p.i2p' (head bde4ef3680071b416b3528bad4c16245964f432a)
            to branch 'i2p.i2p.zzz.test2' (head 183d2a30edd10165451d0cbbf75636f3b1dfda16)
Logger: Configurable flush interval
SusiMail: Add save-as button
Fix encoding for filename in Content-Disposition header
New icon from Silk, same license as the others
Profiles: Change slice selection argument from an int to an enum for clarity
propagate from branch 'i2p.i2p' (head b4b595d294ace07f7fde583957d8e00e96af347c)
            to branch 'i2p.i2p.zzz.test2' (head 90c482d231ea639bff8d37d390dac081e361f48f)
Data: Disallow duplicate keys in a Mapping
Add more clues to file locations in default config files
add more invalid ports
DatabaseStoreMessage: Mask the unused bits in the type field,
in case we ever want to use them for options
RouterInfo: Add convenience method getVersion()
use new getVersion()
show b32 for local leasesets too
reduce auto-stop threshold again
I2PTunnel: Reduce i2ptunnel threads, more thread pooling.
Big savings is on client side (two less threads per connection)
 - Move client pool from static inI2PTunnelClientBase to TCG.
 - Use client pool for some server threads
 - Run some things inline that were formerly threads
 - Client-side I2PTunnelRunner thread used to do nothing but start 2 more
   threads; now it runs one inline (like we do for server-side HTTP)
 - Javadocs and cleanups
Was originally intended to reduce load for high-traffic servers
but most of the savings for now is on the client side.
Ref: http://zzz.i2p/topics/1741
Todo: Figure out how to run the HTTP client-side gunzipper inline too
Todo: More server-side improvements

---

Client side:

before:
4-5 threads, 1-2 pooled

  I2PTunnel Client Runner (BlockingRunner from client pool)
      starts I2PTunnelRunner or I2PTunnelHTTPClientRunner and exits
          starts StreamForwarder toI2P and waits
          starts StreamForwarder fromI2P and waits
              starts HTTPResponseOutputStream (HTTP gunzip only) (from client pool)
now:
2-3 threads, 1-2 pooled

  I2PTunnel Client Runner (BlockingRunner from client pool)
      runs I2PTunnelRunner or I2PTunnelHTTPClientRunner inline
          starts StreamForwarder toI2P and waits
          runs StreamForwarder fromI2P inline
              starts HTTPResponseOutputStream (HTTP gunzip only) (from client pool)

---

Server side:

before:
1-4 threads, 0-1 pooled

  Server Handler Pool (Handler from server pool) execpt for standard server, blockingHandle() inline in acceptor
      starts I2PTunnelRunner or CompressedRequestor and exits
          starts StreamForwarder toI2P and waits   (inline for HTTP)
          starts StreamForwarder fromI2P and waits  (except not for HTTP GET)

now:
1-4 threads, 0-2 pooled

  Server Handler Pool (Handler from server pool) execpt for standard server, blockingHandle() inline in acceptor
      starts I2PTunnelRunner or CompressedRequestor and exits (using client pool)
          starts StreamForwarder toI2P and waits   (inline for HTTP)
          starts StreamForwarder fromI2P and waits  (except not for HTTP GET)
propagate from branch 'i2p.i2p.zzz.test2' (head 0feb2e6806927f68c7333aaa0892de185bb2629c)
            to branch 'i2p.i2p' (head 0482fa843cb1e9d7ec281440056eef3a0ab07bdb)
javadoc
cleanup
more argument checking, javadocs
javadocs