SSO: fix settings merge for SAML fields

[dmihai]

What is this feature?

With this fix we make sure that we don't merge the following fields: certificate, certificate_path, private_key, private_key_path, idp_metadata, idp_metadata_path, idp_metadata_url from system settings. We know that the DB settings already contain a valid value from each group (certificate, private_key, idp_metadata) because the DB settings has been validated before storing them into DB.

Why do we need this feature?

We don't want to have more than 1 value from a group of settings after DB and system settings has been merged.

Who is this feature for?

Anyone using SSO and SAML.

Which issue(s) does this PR fix?:

Fixes #

Special notes for your reviewer:

Please check that:

• It works as expected from a user's perspective.
• If this is a pre-GA feature, it is behind a feature toggle.
• The docs are updated, and if this is a notable improvement, it's added to our What's New doc.

[mgyongyosi]

Just to be extra defensive, should we also add a check for making sure that the isMergingAllowed is only applied to SAML settings?

[dmihai]

I think we should keep the SSO settings service as generic as possible without introducing too much logic specific to individual providers. Also at some point maybe we want to use this new functionality for Oauth as well. Client ID and client secret are good candidates there. I don't think we would ever want to merge client ID from one source (for example .ini file) with the client secret from a different source (such as SSO settings).

[kalleep]

I agree with @dmihai that we for sure should keep this generic and try to not add provider specific things here. Another way to do this would be to extend the provider interface with this functionality, or add an optional interface that providers can implement. That way we can make sure we don't block for other provider in case of key collision.