Add exporting SSL/TLS master key log feature

[huangqiangxiong]

@ejona86 Could you help to review this PR?

Enable this feature by setting the system property in command argument

   -Dio.netty.ssl.masterKeyHandler=true

or in java code

   System.setProperty(SslMasterKeyHandler.SYSTEM_PROP_KEY, "true");

The keys will be written to the log named "io.netty.wireshark" in the warnning level. To export the keys to a file, you can configure log factory like: (log4j.xml for example)

...
<appender name="key-file" class="org.apache.log4j.RollingFileAppender">
	<param name="file" value="d:/keyfile.txt"/>
	<layout class="org.apache.log4j.PatternLayout">
		<param name="ConversionPattern" value="%m%n"/>
	</layout>
</appender>
<category name="io.netty.wireshark">
	<priority value="DEBUG" />
	<appender-ref ref="key-file" />
</category>
...

Wireshark can analyze the messages gRPC over TLS with this key log file.

There is a sample capture and key log file generated by using this commit:

• grpc_person_search_protobuf_and_json_tls.pcapng -- Person search gRPC sample capture (port 60051 for protobuf payload and 60052 for json payload).
• keylog.txt --- grpc_person_search_protobuf_and_json_tls.keylog.txt -- Key log file for above capture.

You can refer to Wireshark gRPC wiki page for getting the
person_search_service.proto and addressbook.proto files, and how to set the Wireshark for parsing gRPC network traffic.

And put the path of keylog.txt in the key log preference in Preferences->Protocols->TLS->(Pre)-Master-Secret log filename.

Finally decode traffic on tcp port 60051 and 60052 as TLS.

close #7199

[ejona86]

We shouldn't be using internal classes to netty, even in a test. And in this case we can just use normal java.util.logging, at the only cost of more annoying assertions. See ThreadLocalContextStorageTest.java for an example test that checks java.util.logging logs.

Note that will mean many of my comments may be invalidated because you'll swap to a new approach. That is fine. You may find some of the comments interesting though.

[huangqiangxiong]

We shouldn't be using internal classes to netty, even in a test. And in this case we can just use normal java.util.logging, at the only cost of more annoying assertions. See ThreadLocalContextStorageTest.java for an example test that checks java.util.logging logs.

Note that will mean many of my comments may be invalidated because you'll swap to a new approach. That is fine. You may find some of the comments interesting though.

Thank you for your comments. I have updated the commits (test case) according to your comments.

[ejona86]

@ericgribkoff, could you review? I think you were on support rotation at the time, which is why I added you.

[ericgribkoff]

@huangqiangxiong Sorry for the delay, This is now merged. Thanks for this change!