[docs] Convert titles to sentense case (#21426)

* Convert documentation titles to sentense case

* Docker, Google, Foundry, Cloud proper case

website/content/docs/plugins/index.mdx

@@ -5,7 +5,7 @@ description: Learn about Vault's plugin system.
 ---
 
 
-# Plugin System
+# Plugin system
 
 Vault supports 3 types of plugins; auth methods, secret engines, and database
 plugins. This concept allows both built-in and external plugins to be treated
@@ -21,12 +21,12 @@ be registered.
 See [Plugin Upgrade Procedure](/vault/docs/upgrading/plugins#plugin-upgrade-procedure)
 for details on how to upgrade a built-in plugin in-place.
 
-## Built-In Plugins
+## Built-In plugins
 
 Built-in plugins are shipped with Vault, often for commonly used integrations,
 and can be used without any prerequisite steps.
 
-## External Plugins
+## External plugins
 
 External plugins are not shipped with Vault and require additional operator
 intervention to run.
@@ -45,7 +45,7 @@ reused across all mounts of a given type.
 -> **NOTE:** See the [Vault Integrations](/vault/integrations) page to find a
 curated collection of official, partner, and community Vault plugins. 
 
-## Plugin Versioning
+## Plugin versioning
 
 Vault supports managing, running and upgrading plugins using semantic version
 information.
@@ -62,7 +62,7 @@ for any available plugins whose type and name match:
 * The plugin with the most recent semantic version among any registered versions
 * The plugin built into Vault
 
-### Built-In Versions
+### Built-In versions
 
 Vault will report a version for built-in plugins to indicate what version of the
 plugin code got built into Vault as a dependency. For example:

website/content/docs/plugins/plugin-architecture.mdx

@@ -4,7 +4,7 @@ page_title: External Plugin Architecture
 description: Learn about Vault's plugin architecture.
 ---
 
-# External Plugin Architecture
+# External plugin architecture
 
 Vault's external plugins are completely separate, standalone applications that Vault
 executes and communicates with over RPC. This means the plugin process does not
@@ -19,7 +19,7 @@ when enabling it.
 -> **NOTE:** See the [Vault Integrations](/vault/integrations) page to find a
 curated collection of official, partner, and community Vault plugins.
 
-## External Plugin Lifecycle
+## External plugin lifecycle
 
 Vault external plugins are long-running processes that remain running once they are
 spawned by Vault, the parent process. Plugin processes can be started by Vault's
@@ -46,7 +46,7 @@ plugins, these processes should not be terminated by anything other than Vault.
 If a plugin process is shutdown out-of-band, the plugin process will be lazily
 loaded when a request that requires the plugin is received by Vault.
 
-### External Plugin Scaling Characteristics
+### External plugin scaling characteristics
 
 External plugins can leverage [Performance Standbys](/vault/docs/enterprise/performance-standby)
 without any explicit action by a plugin author. The default behavior of Vault
@@ -57,7 +57,7 @@ code will then forward the full original request transparently to the active
 node. In other words, plugins can scale horizontally on Vault Enterprise
 without any effort on the plugin author's part.
 
-## Plugin Communication
+## Plugin communication
 
 Vault communicates with external plugins over RPC. To secure this
 communication, Vault creates a mutually authenticated TLS connection with the
@@ -74,14 +74,14 @@ detection (e.g. Consul), Vault will automatically attempt to determine the
 ~> Note: Prior to Vault version 1.9.2, reading the original connection's TLS
 connection state is not supported in plugins.
 
-## Plugin Registration
+## Plugin registration
 
 An important consideration of Vault's plugin system is to ensure the plugin
 invoked by Vault is authentic and maintains integrity. There are two components
 that a Vault operator needs to configure before external plugins can be run- the
 plugin directory and the plugin catalog entry.
 
-### Plugin Directory
+### Plugin directory
 
 The plugin directory is a configuration option of Vault and can be specified in
 the [configuration file](/vault/docs/configuration).
@@ -93,7 +93,7 @@ added to Vault.
 
 @include 'plugin-file-permissions-check.mdx'
 
-### Plugin Catalog
+### Plugin catalog
 
 The plugin catalog is Vault's list of approved plugins. The catalog is stored in
 Vault's barrier and can only be updated by a Vault user with sudo permissions.
@@ -126,7 +126,7 @@ $ vault write sys/plugins/catalog/database/myplugin-database-plugin \
 Success! Data written to: sys/plugins/catalog/database/myplugin-database-plugin
 ```
 
-### Plugin Execution
+### Plugin execution
 
 When a backend wants to run a plugin, it first looks up the plugin, by name, in
 the catalog. It then checks the executable's SHA256 sum against the one
@@ -138,13 +138,13 @@ settings. Like Vault, plugins support [the use of mlock when available](/vault/d
 and each plugin executable in your [plugins directory](/vault/docs/plugins/plugin-architecture#plugin-directory)
 must be given the ability to use the `mlock` syscall.
 
-### Plugin Upgrades
+### Plugin upgrades
 
 External plugins may be updated by registering and reloading them. More details
 on the upgrade procedure can be found in
 [Upgrading Vault Plugins](/vault/docs/upgrading/plugins).
 
-## Plugin Multiplexing
+## Plugin multiplexing
 
 To avoid spawning multiple plugin processes for mounts of the same type,
 plugins can implement plugin multiplexing. This allows a single

website/content/docs/plugins/plugin-development.mdx

@@ -4,7 +4,7 @@ page_title: Plugin Development
 description: Learn about Vault plugin development.
 ---
 
-# Plugin Development
+# Plugin development
 
 ~> Advanced topic! Plugin development is a highly advanced topic in Vault, and
 is not required knowledge for day-to-day usage. If you don't plan on writing any
@@ -31,9 +31,9 @@ backend running the plugin.
 ~> Note: Plugins should be prepared to handle multiple concurrent requests
 from Vault.
 
-## Serving A Plugin
+## Serving a plugin
 
-### Serving A Plugin with Multiplexing
+### Serving a plugin with multiplexing
 
 ~> Plugin multiplexing requires `github.com/hashicorp/vault/sdk v0.5.4` or above.
 
@@ -75,7 +75,7 @@ func main() {
 And that's basically it! You would just need to change `myPlugin` to your actual
 plugin.
 
-## Plugin Backwards Compatibility with Vault
+## Plugin backwards compatibility with Vault
 
 Let's take a closer look at a snippet from the above main package.
 
@@ -113,7 +113,7 @@ instead implement the
 [`PluginVersioner`](https://github.com/hashicorp/vault/blob/sdk/v0.6.0/sdk/logical/logical.go#L150-L154)
 interface directly.
 
-## Building a Plugin from Source
+## Building a plugin from source
 
 To build a plugin from source, first navigate to the location holding the
 desired plugin version. Next, run `go build` to obtain a new binary for the
@@ -121,7 +121,7 @@ plugin. Finally,
 [register](/vault/docs/plugins/plugin-architecture#plugin-registration) the
 plugin and enable it.
 
-## Plugin Development - Resources
+## Plugin development - resources
 
 For more information on how to register and enable your plugin, refer to the
 [Building Plugin Backends](/vault/tutorials/app-integration/plugin-backends)
@@ -132,7 +132,7 @@ Other HashiCorp plugin development resources:
 * [vault-auth-plugin-example](https://github.com/hashicorp/vault-auth-plugin-example)
 * [Custom Secrets Engines](/vault/tutorials/custom-secrets-engine)
 
-### Plugin Development - Resources - Community
+### Plugin development - resources - community
 
 See the [Vault Integrations](/vault/integrations) page to find Community
 plugin examples/guides developed by community members. HashiCorp does not

website/content/docs/plugins/plugin-management.mdx

@@ -6,7 +6,7 @@ description: >-
   plugin system.
 ---
 
-# Plugin Management
+# Plugin management
 
 External plugins are the components in Vault that can be implemented separately
 from Vault's built-in plugins. These plugins can be either authentication or
@@ -20,7 +20,7 @@ Consul), Vault will automatically attempt to determine the `api_addr` as well.
 Detailed information regarding the plugin system can be found in the
 [internals documentation](/vault/docs/plugins).
 
-## Registering External Plugins
+## Registering external plugins
 
 Before an external plugin can be mounted, it needs to be
 [registered](/vault/docs/plugins/plugin-architecture#plugin-registration) in the
@@ -35,7 +35,7 @@ $ vault plugin register -sha256=<SHA256 Hex value of the plugin binary> \
 Success! Registered plugin: passthrough-plugin
 ```
 
-## Enabling/Disabling External Plugins
+## Enabling/Disabling external plugins
 
 After the plugin is registered, it can be mounted by specifying the registered
 plugin name:
@@ -60,7 +60,7 @@ Disabling an external plugins is identical to disabling a built-in plugin:
 $ vault secrets disable my-secrets
 ```
 
-## Upgrading Plugins
+## Upgrading plugins
 
 Upgrade instructions can be found in the [Upgrading Plugins - Guides][upgrading_plugins]
 page.