Backport of add tip for how to force a secrets engine disable into release/1.8.x (#14468)

* backport of commit 8aef67766926213f0b0e3f2d733aa987e630cdc4

* backport of commit 7fe721670e53bcc153092591a973be8d7e2b0528

* backport of commit 9b1cca294fb47db904a0480364d44ac8362ca187
Co-authored-by: Stephen Wayne <swayne@hashicorp.com>

website/content/docs/commands/secrets/disable.mdx

@@ -30,3 +30,20 @@ $ vault secrets disable aws/
 
 There are no flags beyond the [standard set of flags](/docs/commands)
 included on all commands.
+
+## Force Disable
+
+Because `secrets disable` revokes secrets associated with this mount, there can
+be errors that prevent the secrets engine from being disabled if the revocation
+fails.
+
+The best way to resolve this is to figure out the underlying issue, and then
+disable the secrets engine once that has been solved. Often, this can be as
+simple as increasing the timeout (in the event of timeout errors).
+
+For recovery situations where the secret has been manually removed from the
+secrets backing service, one can "force" a secrets engine disable in Vault by
+performing a [prefix force revoke](/docs/commands/lease/revoke) on the mount
+prefix, followed by a `secrets disable` when that completes. Note that this
+method may result in dangling credentials if the underlying secrets were not
+manually cleaned up. This is meant for extreme circumstances.