Backport of docs/consul: rename the Vault secret engine for Consul integration into release/1.13.x

[krastin]

Description

There was feedback from our Support team about customers facing an issue following the documentation from the Vault for Consul: System integration into the Vault for Consul: Data integration. The former defines a consul-named Vault secret engine, but the latter runs commands and config against a secrets-named Vault secret engine - no doubt a leftover from times where the default secret engine from running Vault in -dev mode was used to showcase functionality in the docs.

Furthermore, because of the secret engine name consul, the customers were confused and expected the secret engine to be of the Consul type and not the KV type.

With that in mind, this PR changes the docs in the following way:

• The Vault secret engine created for use with Consul has been renamed to consul-kv
  • to stress the fact that it is a KV type engine and not a Consul type engine
  • to move away from the default secrets engine as this would be unadvisable to run in Production systems, and possibly even dangerous if the default secrets engine is indeed being used
• The path secrets is being used for all token-related configuration so that in Production environments, that specific path can be allowed/disallowed read/write access easier for separate admin and non-admin user roles.

Testing & Reproduction steps

N/A

Links

Related Docs: Vault as the Secrets Backend (K8s)

PR Checklist

• updated test coverage
• external facing docs updated
• appropriate backport labels added
• not a security concern

[hc-github-team-consul-core]

🤔 This PR has changes in the website/ directory but does not have a type/docs-cherrypick label. If the changes are for the next version, this can be ignored. If they are updates to current docs, attach the label to auto cherrypick to the stable-website branch after merging.