to branch 'i2p.i2p.zzz.test2' (head 68ca880caf69a06c0fd01fc70675df795aef1de2)

  - Fix ConnectionAcceptor not restarting after tunnel
    restart, preventing incoming connections
  - locking tweaks
  - cleaner reschedule tweaks
  - don't store server socket locally
  - constructor tweaks / finals
  - Stop acceptor when tunnel disconnects
  - javadocs

     and 'c4f7358a50c9982c5d63e9e5201f4e3f9562422f'

I2PTunnel: Don't send 'X-Forwarded-For' on HTTP server tunnels for anonymity reasons (reported by 'trixie' on IRC).

          (thx str4d)

not restarting correctly, caused by previous checkin

 - Recheck completion status just before sending out a wrapped message
 - log tweaks

  a client socket manager configured with i2cp.newDestOnResume,
  or a shared client.
  This prevents lots of orphaned StreamingTimer threads.
  There are still cases where these threads may stick around,
  when a tunnel is stopped but not restarted. We don't know in
  some cases when a tunnel could be restarted and when it can't.
  destroySocketManager() should always be called when discarding a
  SocketManager but i2ptunnel doesn't do that now. More to do,
  but this fixes the most common case of leaked threads.
  Related tickets: ##642 #961

can be private and the lookup for the form is more efficient.

   This will improve network capacity.
   Apparent problems with lower limits were actually due to
   unrelated bugs that were fixed by 0.9.8.1-22.
   This can go lower still; I've been testing 33% without issues.

            to branch 'i2p.i2p.zzz.test2' (head 6263bb149b8301059d0471bcc1d47caeca660f4e)

    Wait a while and recheck if a recent ping file is there,
    so that a crashed router doesn't prevent a restart (ticket #633)