and the peer doesn't have a severe penalty in the CapacityCalculator forever.
This may fix the tunnel build problems that started in -10. Or not.

   due to int/long problem, they were being corrupted
   and then looked up as IPv4

     and 'b324a96172089b549e53fb1c0c2a01807fe64699'

 - Increase threshold for idle timeout reduction from 33% to 60%.
   This was reduced from 75% to 33% in -10 and it caused significant
   tunnel build problems, for reasons that aren't entirely clear.
 - Don't change the SSU idle timeout quicker when firewalled.
 - log tweaks

The old full-page translations of help.jsp are deprecated. The help text will
be tagged for translation on Transifex.

 - Make dest hash final
 - Ensure allowZeroHop is always true for exploratory

   and Opera (ticket #1093)

     and 'fa8975b2dbcb60d5f181bc21fc1245d5f82baef0'

   - Build a new exploratory fallback tunnel in the BuildExecutor
     loop if we run out.
   - Don't use closest expl. tunnel as the paired tunnel for a build,
     use a random one instead (partially back out change from -12)
   - Log tweaks

   - Don't discard an encrypted DSRM received
     down a tunnel, just strip the hashes like we do for unencrypted
   - Send a store of our own encrypted LS received down a tunnel to
     the InNetMessagePool so the FloodfillVerifyStoreJob will see it.
 * NetDB: Fix LS store verifies with encrypted replies
   by storing the tagset with the correct SKM for the inbound tunnel used.
   Broken since 0.9.7 when it was introduced.

   change, by querying the config instead of StatSummarizer to
   determine if a stat is graphed.
  - Don't append to a string in a loop
  - parseConfig() return a Set instead of List to avoid O(n**2) behavior
    when deteriming config changes

   - Ensure minimum randomized initial conn throttle period
   - Change order of throttle checks again
   - Don't continue throttle checks if throttled

   caused by bad fix for ticket #1070

   - Don't use fallback expl. tunnels as the paired tunnel
     for a client tunnel build.
     This will cause more client tunnel breakage but it's
     really bad to use a zero-hop for this.
   - Fix selection of an expl. tunnel close to a hash
   - Don't update build generation stat if the generation failed
   - log tweaks

   we were picking the not-failing peers in-order for early expl. tunnel builds

   to prevent correlation