Improve the Vault CA Provider's resiliency for leaf signing

Feature Description

Add a resiliency feature to the [Vault CA provider](https://github.com/hashicorp/consul/blob/main/agent/connect/ca/provider_vault.go) to sign leaf certificates without using Vault.

Use Case(s)

Consul Connect client agents require a new leaf certificate (`auto_enrypt`) prior to joining the service mesh. When Vault is unavailable the client will not receive a leaf certificate from the server cluster's leader. Service owner scale-up events will not increase capacity due to the failure, seriously impacting user experience.

Analysis:

The following documentation indicates [a datacenter generates its own intermediate CA](https://www.consul.io/docs/connect/connect-internals#certificate-authority-federation). The side effect is a highly resilient architecture.

This is not the case with the Vault CA provider. The [leaf signing function](https://github.com/hashicorp/consul/blob/main/agent/connect/ca/provider_vault.go#L514-L517) has a real-time hard dependency on Vault for all leaf certificate signing.

I am proposing the same behavior as the built-in CA provider to generate the intermediate signing certificate (signed by the Vault root CA). And to use the same for all leaf signing requests. This would improve resiliency and substantially reduce latency for new client agents.

Start with agent/connect/ca/provider_vault.go, especially the leaf signing function around lines 514-517, and compare it with the built-in CA provider behavior described in the issue. Trace how the Vault root CA and intermediate signing certificate are handled. Done means leaf signing can use a locally available intermediate certificate when Vault is unavailable, with relevant behavior covered by tests if the existing provider test locations identify them.

Written by the indexing model from the issue text.