Support enable/disabling SSL client authentication on the management port without overriding SSL parameters

Continuing discussion from #14985, I would like to continue discussion and agree on the solution.

CURRENT IMPLEMENTATION

Management port inherits all SSL settings from the server port, in other words by default management.server.ssl = server.ssl, while any setting at management.ssl.* starts from a fresh management.ssl settings.

This is convenience in most of the cases as in most cases the server side settings are specified and matches both the server and management settings and no need to specify any override of management port settings.

I guess that the common case of design is for disabling management port SSL by management.server.ssl.enabled=false, which is good enough and then we do not care about not inheriting settings from server but start fresh.

However, when specifying client side authentication using client-auth and key-* on the server.ssl.* to provide client authentication to remote side, it sometimes makes sense to either disable this for management port or change the identity without impacting the server side settings, for example protocol, ciphers, enable-protocols etc...

The problem is that once a single parameter is specify at management.server.ssl.* it requires specifying all parameters again, for example:

server:
  ssl:
    enable: true
    protocol: TLSv1.2
    trust-store: trust.jks
    key-store: key.jks
    client-auth: need
 management:
  server:
    ssl:
      enable: true
      protocol: TLSv1.2
      trust-store: trust.jks
      client-auth: none

Notice that the protocol and trust-store should be repeated in the management statement just to turn client authentication off.

EXPECTED IMPLEMENTATION

Separate the server SSL settings from the client SSL settings while keeping backward compatibility.

I suggest to move SSL client setting client-auth and key-* to ssl-client object, and as fallback (if unset) consult the ssl object.

For example:

server:
  ssl:
    enable: true
    protocol: TLSv1.2
    trust-store: trust.jks
  ssl-client:
    key-store: key.jks
    client-auth: need
 management:
  server:
    ssl-client:
      client-auth: none

or:

server:
  ssl:
    enable: true
    protocol: TLSv1.2
    trust-store: trust.jks
  ssl-client:
    key-store: key.jks
    client-auth: need
 management:
  server:
    ssl-client:
      key-store: key-management.jks
      client-auth: need

Backward compatibility is maintained using fallback to server.ssl.*.

server:
  ssl:
    enable: true
    protocol: TLSv1.2
    trust-store: trust.jks
    key-store: key.jks
    client-auth: need
 management:
  server:
    ssl:
      key-store: key-management.jks
      client-auth: need

Any other method will be gladly accepted :)

Start with the management-port SSL configuration described here and the discussion in #14985. Trace how server.ssl and management.server.ssl currently inherit settings, then evaluate a backward-compatible separation of server and client SSL settings. Done means the management port can change client authentication or identity without repeating unrelated SSL parameters.