Enable mTLS on connections between inputs and the shipper

[cmacknz]

• Relates Beats shipper output will not enable TLS beats#34321

Connections between inputs like Beats and the shipper are intended to be encrypted using mTLS. This is currently disabled because of some challenges in configuring the server based on the way the configuration is provided by the agent, see #224.

elastic-agent-shipper/controller/controller_client.go

Lines 107 to 123 in fff35d3

	func (c *clientHandler) startgRPC(unit *client.Unit, cfg config.ShipperConnectionConfig) {
	//TODO: until we get TLS config fixed/figured out, run in insecure mode
	// certPool := x509.NewCertPool()
	// for _, cert := range cfg.Shipper.Server.TLS.CAs {
	// if ok := certPool.AppendCertsFromPEM([]byte(cert)); !ok {
	// c.reportError("error appending cert obtained from input in shipper startup", err, outUnit)
	// return
	// }
	// }
	_ = unit.UpdateState(client.UnitStateConfiguring, "starting gRPC server", nil)
	creds := insecure.NewCredentials() //:= credentials.NewTLS(&tls.Config{
	// ClientAuth: tls.RequireAndVerifyClientCert,
	// ClientCAs: certPool,
	// GetCertificate: c.getCertificate,
	// MinVersion: tls.VersionTLS12,
	// })

Regardless of the way TLS is configured, it needs to be possible to enable TLS for connections between the inputs and the shipper. The scope of this issue is to reenable TLS between the inputs and shipper, and measure the performance impact of enabling TLS so we can decide if it needs to be optional.

Acceptance Criteria:

• A test exists proving that a shipper client can communicate with the shipper server using a TLS encrypted connection.
• A performance comparison between the shipper with TLS and the shipper without TLS has been documented.

[cmacknz]

Another aspect of this besides encryption is the authentication element added by mTLS, to ensure that any user on a machine can publish events through the shipper.

Without mTLS we are relying on the unix socket/named pipe created for communication with the shipper being owned by root, which prevents non-root users from writing through the shipper. This is likely fine for an initial release but would still want to add an explicit authentication step in the future.