Send error responses for timeout, EOF, and bad registration.
Only affects "user" mode, not webirc.
detab
move private fields to top

i2ptunnel:
- Better timeout handling when reading headers in HTTP server (improved fix for ticket #723)
  Enforce total header timeout with new readLine()
- Prep for returning specific HTTP errors to client on request timeout and header errors,
  instead of just closing socket... further work to be in i2p.i2p.zzz.test2 branch
Streaming:
- Fix read timeout on input stream - was waiting too long, often twice as long as timeout, or more
  Enforce total timeout even when notify()ed
- Fix read() returning 0 on read timeout instead of -1 (possible fix for ticket #335)
  This prevents passing partial headers to server on timeout
- Fix javadocs for read timeout to match current behavior
- Fix StandardSocket SoTimeout to account for differences with I2PSocket readTimeout
- log tweaks

broken by new state code

better error message to client
javadocs

escape and truncate URL on error page

display new error page in HTTP client (ticket #643)
javadocs

Reseed: Better status feedback and cleanup in summary bar

  - Move multipart form support from susimail to jetty-i2p.jar
    so console can use it
  - Add multipart form support to formhandler.jsi and FormHandler.java
Reseed:
  - Fix zip magic number
  - Finish manual reseed from local file
package.html files for jetty-i2p.jar

  - Add form to manually reseed from zip or su3 URL
    (result status not yet working)
  - Add form to manually reseed from local zip or su3 file
    (not yet working, needs multipart/form-date moved from susimail)
  - Add form to create reseed zip file to share
    (working)
  - Backend support and refactoring in reseed code

Prop from i2p.i2p.zzz.upnp, containing:
Cyberlink for Java v3.0 + (2015-02-15) from github
See branch revs for more info and fixups.
Previous was Cyberlink for Java v2.1 (2011-09-16) from SVN.
From a scan of the 2.1-to-3.0 diff, it's mostly
formatting changes, getting rid of DOS line endings,
and a couple of new features we don't need.
I see very few fixes. And the Device.getAbsoluteURL()
"fixes" did not work in my testing, I had to fix them again.
Unlikely to fix any of the open UPnP tickets #481 #725 #728 #1194 #1480.
But now we're current.

we are already connected to him
(from ISJ only; does not affect exploration, verifies, LSes, ...)

   - Fix overload dropping
   - Add drop count to job stats
   - Decrease overload threshold again
   - Concurrent tweaks

  - Drop garlic message decryption jobs on overload
  - Decrease overload threshold

 - Use lifetime average value for job lag
 - Change the job lag limit to less than 25ms
 - Consider and set the limit of backlogged tunnels to less than 5

Reduce log level for ignored clock adjustment

receiving a message. Possible workaround for tickets #551, #1075, #1411.
Root cause of problem not yet found.
- Increase threshold for loop throttle, this probably isn't the problem.
- Log tweaks

This is just a simple workaround, root cause unknown.
May need tuning.

 - Sort introducers in router address, so we won't force a republish
due to a different ordering of the same introducers
- Don't publish an address if we need introducers but don't have any,
so the user won't see a 'firewalled with inbound NTCP enabled' message

caused by change in 0.9.17 removing IP/port from published address
when firewalled. We must now keep a local unpublished address
also, containing the detected IP/port.

  - Rescan for devices periodically and when reachability changes (tickets #661, #959)
  - Don't put "I2P" in registered protocol name
  - Add uptime to UPnP info
  - HTML escaping
  - Remove static log on Android
  - Javadocs and cleanups

PLRIJ interval was 37-50 minutes. Reduce that by 4x,
but for 3 out of 4 times, only publish if something changes,
including cost. 4th time, always publish, as before.
This will hopefully reduce routers getting slammed to
conn limits on a transport.

Tunnels: Cleanup, catch more cases of zero-hop configuration
ClientAppConfig: Start i2ptunnel sooner
  Since BuildRequestor won't use a zero-hop exploratory as a paired tunnel
  for client builds, it's now safe to start client tunnels
  before the expl. tunnels are ready. This will save up to 90 seconds.