When multiples CA are presents on the system we cannot ensure that a
specific one was used to validates the chains exposer by the server.
This PRs adds a `ca_sha256` option to the `tlscommon.TLSConfig` that is used by all
the code that has to create a TCP client with TLS support.

When the option is set, it will hook a new callback in the validation
chains that will inspect the verified and validated chains by Go to
ensure that a lets a certificate in the chains match the provided
sha256.

Usage example for the Elasticsearch output.

```
output.elasticsearch:
  hosts: [127.0.0.1:9200]
  ssl.ca_sha256: <base64_encoded_sha1>
```

You can generate the pin using the **openssl** binary with the
following command:

```
openssl x509 -in ca.crt -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
```

OpenSSL's [documentation](https://www.openssl.org/docs/manmaster/man1/dgst.html)

You will need to start Elasticsearch with the following options

```yaml
xpack.security.enabled: true
indices.id_field_data.enabled: true
xpack.license.self_generated.type: trial
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.key: /etc/pki/localhost/localhost.key"
xpack.security.http.ssl.certificate: /etc/pki/localhost/localhost.crt"
xpack.security.http.ssl.certificate_authorities: /etc/pki/ca/ca.crt"
```

This pull request also include a new service in the docker-compose.yml
that will start a new Elasticsearch server with TLS and security
configured.