[#2939] Fix SslContext usage in the examples for client side

Motivation:

We incorrectly used SslContext.newServerContext() in some places where a we needed a client context.

Modifications:

Use SslContext.newClientContext() when using ssl on the client side.

Result:

Working ssl client examples.
HTTP/2 Codec Read/Write Restructure

Motivation:
The HTTP/2 codec has some duplication and the read/write interfaces are not cleanly exposed to users of the codec.

Modifications:
-Restructure the AbstractHttp2ConnectionHandler class to be able to extend write behavior before the outbound flow control gets the data
-Add Http2InboundConnectionHandler and Http2OutboundConnectionHandler interfaces and restructure external codec interface around these concepts

Result:
HTTP/2 codec provides a cleaner external interface which is easy to extend for read/write events.
Send a websocket close frame with status code when receiving invalid frames

Motivation:

According to the websocket specification peers may send a close frame when
they detect a protocol violation (with status code 1002). The current
implementation simply closes the connection. This update should add this
functionality. The functionality is optional - but it might help other
implementations with debugging when they receive such a frame.

Modification:

When a protocol violation in the decoder is detected and a close was not
already initiated by the remote peer a close frame is
sent.

Result:

Remotes which will send an invalid frame will now get a close frame that
indicates the protocol violation instead of only seeing a closed
connection.
HTTP/2 Unit Tests Synchronized Collections

Motivation:
The HTTP/2 unit tests are collecting responses read events which are happening in a multithreaded environment.
These collections are currently not synchronized or thread safe and are resulting in verification failures.

Modifications:
-Modify unit tests that use collections to store results for verifiction to be thread safe

Result:
Tests should not fail because of syncrhonization issues while verifying expected results.
Fixing bugs in HTTP/2 pipeline exception handling

Motivation:

HTTP/2 codec does not properly test exception passed to
exceptionCaught() for instanceof Http2Exception (since the exception
will always be wrapped in a PipelineException), so it will never
properly handle Http2Exceptions in the pipeline.

Also if any streams are present, the connection close logic will execute
twice when a pipeline exception. This is because the exception logic
calls ctx.close() which then triggers the handleInActive() logic to
execute.  This clears all of the remaining streams and then attempts to
run the closeListener logic (which has already been run).

Modifications:

Changed exceptionCaught logic to properly extract Http2Exception from
the PipelineException.  Also added logic to the closeListener so that is
only run once.

Changed Http2CodecUtil.toHttp2Exception() to avoid NPE when creating
an exception with cause.getMessage().

Refactored Http2ConnectionHandler to more cleanly separate inbound and
outbound flows (Http2ConnectionDecoder/Http2ConnectionEncoder).

Added a test for verifying that a pipeline exception closes the
connection.

Result:

Exception handling logic is tidied up.
Change the operator order of TrafficCounter to calculate the throughput to get the correct result

Motivation:
Currently the last read/write throughput is calculated by first division,this will be 0 if the last read/write bytes < interval,change the order will get the correct result

Modifications:
Change the operator order from first do division to multiplication

Result:
Get the correct result instead of 0 when bytes are smaller than interval
Motivation:

The HTTP/2 tests have been unstable, in particular the
Http2ConnectionRoundtripTest.

Modifications:

Modified fields in Http2TestUtil to be volatile.

Result:

Tests should (hopefully) be more stable.
HTTP/2 unit test missed syncrhonized collection

Motiviation:
PR https://github.com/netty/netty/pull/2948 missed a collection to synchronize in the HTTP/2 unit tests.

Modifications:
synchronize the collection that was missed

Result:
Missed collection is syncronized and initial size is corrected
Adding missing asserts to HTTP/2 tests

Motivation:

Some tests do not properly assert that all requests have been
sent/received, so the failures messages may be misleading.

Modifications:

Adding missing asserts to HTTP/2 tests for awaiting requests and
responses.

Result:

HTTP/2 tests properly assert message counts.
Fix Http/2 example response timeout

Motivation:

The HTTP/2 example can timeout at the client waiting for a response due
to the server not flushing after writing the response.

Modifications:

Updated the server's HelloWorldHttp2Handler to flush after writing the
response.

Result:

The HTTP/2 example runs successfully.
Fixing concurrency issue with HTTP/2 test mocking

Motivation:

Some tests occasionally appear unstable, throwing a
org.mockito.exceptions.misusing.UnfinishedStubbingException. Mockito
stubbing does not work properly in multi-threaded environments, so any
stubbing has to be done before the threads are started.

Modifications:

Modified tests to perform any custom stubbing before the client/server
bootstrap logic executes.

Result:

HTTP/2 tests should be more stable.
Simplifying and centralizing HTTP/2 exception handling logic

Motivation:

Currently, Http2LifecycleManager implements the exception handling logic
which makes it difficult to extend or modify the exception handling
behavior.  Simply overriding exceptionCaught() will only affect one of
the many possible exception paths. We need to reorganize the exception
handling code to centralize the exception handling logic into a single
place that can easily be extended by subclasses of
Http2ConnectionHandler.

Modifications:

Made Http2LifecycleManager an interface, implemented directly by
Http2ConnectionHandler. This adds a circular dependency between the
handler and the encoder/decoder, so I added builders for them that allow
the constructor of Http2ConnectionHandler to set itself as the lifecycle
manager and build them.

Changed Http2LifecycleManager.onHttpException to just
onException(Throwable) to simplify the interface. This method is now the
central control point for all exceptions. Subclasses now only need to
override onException() to intercept any exception encountered by the
handler.

Result:

HTTP/2 has more extensible exception handling, that is less likely to
see exceptions vanish into the ether.
Restoring access to HTTP/2 decoder's listener.

Motivation:

This was lost in recent changes, just adding it back in.

Modifications:

Added listener() accessor to Http2ConnectionDecoder and the default
impl.

Result:

The Http2FrameListener can be obtained from the decoder.
NullPointerException fix in http/2 codec

Motivation:
There is a NPE due to the order of builder initialization in the  class.

Modifications:
-Correct the ordering of initialization and building to avoid NPE.

Result:
No more NPE in  construction.
Improve WebSocket performance

Motivation:

Websocket performance is to a large account determined through the masking
and unmasking of frames. The current behavior of this in Netty can be
improved.

Modifications:

Perform the XOR operation not bytewise but in int blocks as long as
possible. This reduces the number of necessary operations by 4. Also don't
read the writerIndex in each iteration.
Added a unit test for websocket decoding and encoding for verifiation.

Result:

A large performance gain (up to 50%) in websocket throughput.
Avoid vectored writes for small websocket messages

Motivation:
The WebSocket08FrameEncoder contains an optimization path for small messages which copies the message content into the header buffer to avoid vectored writes. However this path is in the current implementation never taken because the target buffer is preallocated only for exactly the size of the header.

Modification:
For messages below a certain treshold allocate the buffer so that the message can be directly copied. Thereby the optimized path is taken.

Result:
A speedup of about 25% for 100byte messages. Declines with bigger message sizes. I have currently set the treshold to 1kB which is a point where I could still see a few percent speedup, but we should also avoid burning too many CPU cycles.
Fix the leak in the WebSocketClientProtocolHandshakeHandler

Motivation:
The WebSocketClientProtocolHandshakeHandler never releases the received handshake response.

Modification:
Release the message in a finally block.

Result:
No more leak
Adding a benchmark for websockets

Motivation:

It is often helpful to measure the performance of connections, e.g. the
latency and the throughput. This can be performed through benchmarks.

Modification:

This adds a simple but configurable benchmark for websockets into the
example directory. The Netty WebSocket server will echo all received
websocket frames and will provide an HTML/JS page which serves as the
client for the benchmark.
The benchmark also provides a verification mode that verifies the sent
against the received data. This can be used for the verification ob
websocket frame encoding and decoding funtionality.

Result:

A benchmark is added in form a further Netty websocket example.
With this benchmark it is easily possible to measure the performance between Netty and a browser
Change client id validation range in codec-mqtt

Motivation:

In MQTT 3.1 specification, "The Client Identifier (Client ID) is between
1 and 23 characters long, and uniquely identifies the client to the
server". But, current client id validation length is 0~23. It must be
1~23. The empty string is invalid client id in MQTT 3.1

Modifications:

Change isValidClientId method. Add MIN_CLIENT_ID_LENGTH.

Result:

The validation check for client id length is between 1 and 23.
Add a test for handover from HTTP to Websocket

Motivation:
I was not fully reassured that whether everything works correctly when a websocket client receives the websocket handshake HTTP response and a websocket frame in a single ByteBuf (which can happen when the server sends a response directly or shortly after the connect). In this case some parts of the ByteBuf must be processed by HTTP decoder and the remaining by the websocket decoder.

Modification:
Adding a test that verifies that in this scenaria the handshake and the message are correctly interpreted and delivered by Netty.

Result:
One more test for Netty.
The test succeeds - No problems