Werk #14982: Agent Encryption: Simplify configuration

This is the second of two Werks to simplify the configuration of the agent encryption. The former ruleset "Encryption (Linux, Windows)" is split up in three rulesets:

The pre-shared secret used for the OpenSSL based encryption is configured in the ruleset "Symmetric encryption (Linux, Windows)". This is the only parameter that is configured here. If it is set, the agent shall send encrypted data using this secret. By default, no such encryption is applied.

This is a boiled down version of the original ruleset. No user interaction is required when updating.

The real-time check related parameters are moved to the dedicated ruleset. See Werk #14652 for details on how this is incompatible.

The server side handling of (un)encrypted data is configured in the new ruleset Enforce agent data encryption. Users can choose how to deal with unencrypted data: use it, or discard it. This configration option is extended, as we now differentiate between TLS encryption and the OpenSSL based symmetric encryption. TLS encrypted data is always considered to be ok, which leaves us with three options:

• "Accept TLS encrypted connections only": All other connections are cosed, and the Check_MK service goes to {CRIT}. Note that by the time we notice that the connection is unencrypted, the unencrypted data is already sent over the network.
• "Accept all types of encryption": TLS encrypted and symmetrically encrypted data is accepted. Unencrypted data is discarded, and the Check_MK service goes to {CRIT}.
• "Accept all incoming data, including unencrypted": This is (and has been) the default.

During update, rules reflecting your current setup are created automatically, no user interaction is required.

Note that for users of the agent controller, the configuration of the pre-shared secret is not only unneccessary, but also counter productive: It renders the compression implemented in the controller ineffective.

To the list of all Werks