ca: relax (or remove) validation of PrivateKeyType/PrivateKeyBits

[dnephin]

This was added in #10331 as part of #9572.

The current validation works well if Consul is responsible for generating the root CA, but there's no requirement to have Consul generate the root CA. For both the built-in and Vault providers the user can setup the root CA ahead of time, and Consul will use the already configured CA. This manual setup will be required for #11910 (#11598).

For the manually configured root CA scenario, this validation causes problems. An example of the problem can be seen in this test case:

consul/agent/consul/leader_connect_ca_test.go

Lines 649 to 652 in 2881f23

	// TODO: there are failures to init the CA system if these are not set
	// to the values of the already initialized CA.
	"PrivateKeyType": "ec",
	"PrivateKeyBits": 256,

The user is required to specify these values in the Consul config exclusively to get past the validation. The config values will never be used by Consul for the root CA.

Another example is this comment on the issue. The validation is preventing the user from changing the key bits used to generate intermediate certificates.

[dnephin]

If you are seeing this error:

cannot update the PrivateKey{Type,Bits} field without choosing a new PKI mount for the root CA

You can work around the problem by running consul connect ca set-config to change the configuration to include PrivateKeyType, PrivateKeyBits with values that match the CA cert that was created in Vault (docs are here). Unfortunately the error message doesn't tell you which values are expected, but you should be able to look them up by getting the public PEM out of vault (the path is the root_pki_path), and running openssl x509 -noout -text on the PEM. The information should be right below "Public Key Algorithm".

If you see this error when restarting a server (i.e. after an upgrade) this workaround should still work. Consul should allow you to change the config even if the CA system has not been initialized.

If anyone has trouble with this workaround, please comment here.