Enable native & file realms unless explicitly disabled

[tvernum]

At the moment we enable "default_native" and "default_file" realms if there are no other realms in the realm chain.

So, the out-of-the-box experience is that native users work.

If you add a realm to the realm chain you lose both the native and file realm, and are expected to configure them explictly.

So, for example, when an admin configures a SAML realm, but fails to add a native or file realm, then their native users will lose acess to the cluster.
The admin will do some research & work out the problem and then configure the native realm, but will often not add the file realm back.

There are 2 problems here.

1. The experience is painful & unexpected - adding 1 thing breaks something else.
2. File realms are helpful, and ought to be enabled by default, but this process leads to them often being disabled.

I propose that, in ES 8.0, we add a native and file realm to the realm chain unless the configuration explicitly disables them.

I think there are 3 rough options:

1. Add new setting(s) like xpack.security.authc.enable_native that default to true. If true, we add a native & file realm to the realm chain, unless they are already in the realm chain.
2. Don't add any new settings, but always add native & file realms to the realm chain, if they do not already exist. To explicitly disable these realms you would put them in the realm chain with enabled: false.
3. Make it an error to specify a realm chain that lacks the native & file types (but they may be disabled).

Option (3) is the most explicit. The realm chain is always a true reflection of the cluster's security configuration, and we never mess with it behind the scenes. However, it is not very user friendly. The example above of configuring the SAML realm would fail and we would force the admin to jump through hoops to make the node start.

Option (1) doesn't feel like it adds anything over option (2).

Based on favouring user friendliness over explicit (though an admin can chose to be explicit if they want), I favour option (2).

[elasticmachine]

Pinging @elastic/es-security (:Security/Authentication)

[ywangd]

I don't think the code well supports multiple file realms? I mean you can add multiple file realms but they end up using the same backing file. If user configures a file realm with name other than "default_file", I think we should also disable the default one.

With option 2, what should the code do if user writes xpack.security.authc.realms.file.my-own-file-realm.enabled: false. Should we add the default file realm or report error or something else?

[tvernum]

We discussed in the Security Area meeting and agreed that we want to do this (keep file+native realms enabled unless explicitly disabled) but did not reach a consensus on which implementation option was preferred.

I'm removing team-discuss because I think whoever end up picking up this issue can take responsibility for getting input from others and then making a decision.