ca: Support separate Vault providers per DC

[dnephin]

Currently the Connect CA requires that when the Vault provider is used, all Consul DCs must either:

• point at the same Vault cluster
• use Vault replication to mirror the certificate at root_pki_path to all clusters, or
• a user must manually copy the root cert to all clusters

This requirement comes with a number of disadvantages. The manual option is extra work that shouldn't be necessary, and both of the other options require setting separate paths for intermediate_pki_path in every DC, otherwise things are pretty broken.

We can allow a separate Vault cluster per Consul DC by changing the two calls to provider.ActiveRoot in SignCertificate and initializeSecondaryCA to use the root CA that is fetched from the primary DC, instead of attempting to retrieve it directly from Vault.

This would not only enable separate Vault instances, but would also allow someone to use different CA providers per datacenter. While that may not be a desirable long term option, it does seem like a pretty important thing to support for doing an incremental switch over from one provider to another, one DC at a time.

Acceptance Criteria

1. Write a test showing that a separate Vault instance can be used for the primary and secondary Consul DCs, and that the secondary is able to sign leaf certs. The test should both re-initialize the CAManager at least once, and also separately show an update of the configuration. Currently the calls to Provider.ActiveRoot only happen in those scenarios, so we won't notice the problem until those operations are performed.
2. Address the structural problems in the code that make it trivial to re-introduce the problem. Currently ca.Provider interface makes no distinction between the methods that are safe for use in the secondary DC. We should split up this interface into ProviderPrimary and ProviderSecondary. Also, any methods on CAManager should either be safe for both primary and secondary, or they should be explicitly named primaryX or secondaryX to make it clear where they are used. In the future we may be able to split those methods further onto separate types. This work was started in ca: split the Provider interface into Primary/Secondary #11340.