[#2542] HTTP post request decoder does not support quoted boundaries

Motivation:
According to RFC2616 section 19, boundary string could be quoted, but
currently the PostRequestDecoder does not support it while it should.

Modifications:
Once the boundary is found, one check is made to verify if the boundary
is "quoted", and if so, it is "unqoted".

Note: in following usage of this boundary (as delimiter), quote seems no
more allowed according to the same RFC, so the reason that only the
boundary definition is corrected.

Result:
Now the boundary could be whatever quoted or not. A Junit test case
checks it.
[#2544] Correctly parse Multipart-mixed POST HTTP request in case of entity ends with odd number of 0x0D. Port of @fredericBregier 's work.

Motivation:
When an attribute is ending with an odd number of CR (0x0D), the decoder
add an extra CR in the decoded attribute and should not.

Modifications:
Each time a CR is detected, the next byte was tested to be LF or not. If
not, in a number of places, the CR byte was lost while it should not be.
When a CR is detected, if the next byte is not LF, the CR byte should be
saved as the position point to the next byte (not LF). When a CR is
detected, if there is not yet other available bytes, the position is
reset to the position of CR (since a LF could follow).

A new Junit test case is added, using DECODER and variable number of CR
in the final attribute (testMultipartCodecWithCRasEndOfAttribute).

Result:
The attribute is now correctly decoded with the right number of CR
ending bytes.
Fix a bug where SslHandler does not handle SSLv2Hello correctly

Motivation:

When a SSLv2Hello message is received, SSLEngine expects the application buffer size to be more than 30KB which is larger than what SslBufferPool can provide.  SSLEngine will always return with BUFFER_OVERFLOW status, blocking the SSL session from continuing the handshake.

Modifications:

When SSLEngine.getSession().getApplicationBufferSize() returns a value larger than what SslBufferPool provides, allocate a temporary heap buffer.

Result:

SSLv2Hello is handled correctly.
Make sure cancelled Timeouts are able to be GC'ed fast.

Motivation:
At the moment the HashedWheelTimer will only remove the cancelled Timeouts once the HashedWheelBucket is processed again. Until this the instance will not be able to be GC'ed as there are still strong referenced to it even if the user not reference it by himself/herself. This can cause to waste a lot of memory even if the Timeout was cancelled before.

Modification:
Add a new queue which holds CancelTasks that will be processed on each tick to remove cancelled Timeouts. Because all of this is done only by the WorkerThread there is no need for synchronization and only one extra object creation is needed when cancel() is executed. For addTimeout(...) no new overhead is introduced.

Result:
Less memory usage for cancelled Timeouts.
[maven-release-plugin] prepare release netty-3.9.2.Final
[maven-release-plugin] prepare for next development iteration
Update dependency from org.jboss.logging:jboss-logging-spi:2.1.2.GA to org.jboss.logging:jboss-logging:3.1.4.GA
SPDY: fix pushed response NullPointerException
Fix a bug where the data that follows an HTTP upgrade response is lost

Related issue: #2179 and #2173

Motivation:

When a WebSocket server responds to a WebSocket handshake request with
its first WebSocket frame, it is sometimes swallowed by
HttpMessageDecoder.  This issue has been fixed by
4f6ccbbb78c88c82aa02c77fe7592709cfbf7922 in 4 and 5, but was not.

Modification:

Backport the UPGRADED state and the fix for #2173 to HttpMessageDecoder

Result:

The data sent by the server following an HTTP upgrade response is not
lost anymore.
Fire INTEREST_OPS ChannelStateEvent on change in AbstractNioWorker

Motivation:

We forgot to set the flag 'changed' to 'true' after updating
interestOps.

Modifications:

Add a missing 'changed = true;'

Result:

ChannelStateEvent(INTEREST_OPS) is always triggered correctly.
Use our own URL shortener wherever possible
[#2713] Always use correct remote address in ConnectTimeoutException

Motivation:

As we cached ConnectTimeoutException we sometimes ended up using the wrong remote address in the exception message.

Modifications:

Always create a new ConnectTimeException and so make sure we use the connect remote address. This has a bit more overhead because of fill in the stacktrace everytime but as this only happens on connection timeouts it should be ok.

Result:

Always include the correct remote address in ConnectTimeoutException.
[#2718] Add private key decryption to JdkSslServerContext

Backported: d9cccccbb3344997e016e6a3603126ce65705c4d

Motivation:

Currently it is not possible to load an encrypted private key when
creating a JDK based SSL server context.

Modifications:

- Added static method to JdkSslServerContext which handles key spec
  generation for (encrypted) private keys and make use of it.
- Added tests for creating a SSL server context based on a (encrypted)
  private key.

Result:

It is now possible to create a JDK based SSL server context with an
encrypted (password protected) private key.
[#2732] HttpRequestEncoder may produce invalid uri if uri parameters are included.

Motivation:

If the requests contains uri parameters but not path the HttpRequestEncoder does produce an invalid uri while try to add the missing path.

Modifications:

Correctly handle the case of uri with paramaters but no path.

Result:

HttpRequestEncoder produce correct uri in all cases.
Fix a bug where ChannelFuture.setFailure(null) doesn't fail

Motivation:

We forgot to do a null check on the cause parameter of
ChannelFuture.setFailure(cause)

Modifications:

Add a null check

Result:

Fixed issue: #2728
Do not issue a handshake when an SSLEngine is closing/closed

Motivation:

We sometimes get the following exception:

javax.net.ssl.SSLException: SSLEngine is closing/closed
  at sun.security.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:692)
  at sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:734)
  at org.jboss.netty.handler.ssl.SslHandler.handshake(SslHandler.java:433)
  at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1233)
  at org.jboss.netty.handler.ssl.SslHandler.channelDisconnected(SslHandler.java:668)

.. which is triggered when we attempt to issue a handshake even if the
SSLEngine is closed (or being closed).

We don't really need to initiate handshake if:

- SSLEngine is closed already.
- Connection is closed already

Modifications:

Add a boolean parameter to unwrap() and unwrapNonApp() to suppress the
invocation of handshake() when SSLEngine or connection is closed
already.
HttpContentCompressor doesn't need to generate anything if Content-Length is 0

Motivation:

When Content-Encoding is deflate or gzip and Content-Length is 0,
there's no need to generate an empty stream (e.g. 20-byte gzip stream).
We can just produce nothing. At least, it works fine with most modern
browsers. Also, we can skip the instantiation of an encoder entirely by
instantiating it lazily.

Modifications:

Backport HttpContentEncoderTest from 4.0
Add similar tests for HttpContentCompressor to ensure the same tests
work with compression.

Result:

Fixes issue #2321
Fix a bug where SpdySession.getActiveStreams() returns incorrect set

Related issue: #2742

Motivation:

When there are more than one stream with the same priority, the set
returned by SpdySession.getActiveStream() will not include all of them,
because it uses TreeSet and only compares the priority of streams. If
two different streams have the same priority, one of them will be
discarded by TreeSet.

Modification:

- Rename getActiveStreams() to activeStreams()
- Replace PriorityComparator with StreamComparator

Result:

Two different streams with the same priority are compared correctly.
Fix the dead lock while failing SSL pending writes on a closed channel

Related issue: #2093

Motivation:

When a channel with SslHandler is closed with pending writes (either
unencrypted or encrypted), SslHandler.channelClosed() attempts to
acquire a lock and fail the futures of the pending writes.

If a user added a listener to any of the failed futures and the listener
attempts to write something, it will make SslHandler.handleDownstream()
invoked, which also attempts to acquire the same lock.

Because the lock is non-reentrant, even if these two lock acquisitions
are taking place in the same thread, the second attempt will block for
ever.

Modification:

Do not fail the futures while holding a lock.  Notify them after
releasing the lock.

Result:

One less dead lock
Remove StackTraceSimplifier

Related issue: #2735

Motivation:

When an application is under load and experiencing a lot of failure, the
instantiation of DefaultExceptionEvent spends noticeable amount of time
because of StackTraceSimplifier.

Also, StackTraceSimplifier makes people sometimes confused because it
hides the execution path partially.

Modifications:

Remove the use of StackTraceSimplifier

Result:

JVM spends much less time at Throwable.getStackTrace()