Add support for TLS protocol tracing

[ddelnano]

Summary: Add support for TLS protocol tracing

This is the final change to wire up the tls protocol parser and stitcher into stirling. I've also filed #2095 to track supporting tracing TLS handshakes and the application data.

Relevant Issues: N/A

Type of change: /kind feature

Test Plan: New tests verify functionality works end to end

Changelog Message: Added support for tracing TLS handshakes. This can be enabled with --stirling_enable_tls_tracing=1 or through the PX_STIRLING_ENABLE_TLS_TRACING environment variable. Until #2095 is addressed, this will disable tracing the plaintext within encrypted connections.

[ddelnano]

GCC fails if this isn't initialized (buildbuddy failure)

[oazizi000]

Do you have examples of the records we would see? Is version and extensions valid on all those records?

[ddelnano]

This gist shows the output from stirling_wrapper (also copied below). Note: that the content type and version fields will have carnot function support that turn their integer representations into human readable strings. I already have that completed, but wanted to make that its own PR.

record=[
 req=[TLS Frame [len=216 content_type=22 legacy_version=769 handshake_version=771 handshake_type=1 extensions={"server_name":"[\"google.com\"]"}]
 resp=[TLS Frame [len=100 content_type=22 legacy_version=771 handshake_version=771 handshake_type=2 extensions={}]
]

As of now, the tls_events table inserts one record for each TLS handshake. Thus, the version and extensions columns will always have a value. I think it could be useful to support alert, heartbeat, or change cipher messages in the future. These messages don't contain extensions, and while they do have a "version" field, it is the legacy version used in TLS 1.2 and earlier.

[ddelnano]

@oazizi000 after our discussion on the tls_events table schema, I made the following changes in 3f80935:

• Renamed req_type to content_type: this better matches what was already inserted into the table (handshakes) and will map nicely to alerts, heartbeats, etc.
• Removed the extensions column in favor of req_body and resp_body: this allows for storing extensions that exist on both the client and server side and means that the field is no longer specific to handshake records.