Remove Enterprise documentation

[JanMa]

This PR removes all documentation of Vault Enterprise features. Note that I have not yet cleaned all mentions of Vault namespaces, since many APIs of the OSS version return stub namespace information. We need to have a seperate discussion how we want to handle those.

Closes: #23

[joewxboy]

One small change noted.

[cipherboy]

A few more things to remove I think:

[cipherboy@lp10 website]$ gif 'Performance Secondary'
content/docs/release-notes/1.5.0.mdx:25:- A new DR secondary replication dashboard, and an updated performance secondary replication dashboard
content/docs/release-notes/1.7.0.mdx:46:- **Client Controlled Consistency (Enterprise):** New options to use configurable headers to control the consistency of reads after writes to performance secondary clusters and performance standby nodes.
content/docs/upgrading/upgrade-to-1.1.1.mdx:67:possible from a performance secondary. These have been resolved, and these
content/docs/upgrading/upgrade-to-1.1.1.mdx:68:operations may now be run from a performance secondary.
content/docs/upgrading/upgrade-to-1.13.x.mdx:104:If a revocation request comes in to a standby or performance secondary node,
content/docs/upgrading/upgrade-to-1.2.0.mdx:118:possible from a performance secondary. These have been resolved, and these
content/docs/upgrading/upgrade-to-1.2.0.mdx:119:operations may now be run from a performance secondary.
content/docs/upgrading/upgrade-to-1.2.4.mdx:25:after a mount filter has been created on an upstream Performance secondary
content/partials/known-issues/update-primary-data-loss.mdx:19:  Calling `update-primary` on a performance secondary with local data in shared
content/partials/known-issues/update-primary-data-loss.mdx:51:Reindex the performance secondary to update the merkle tree with the missing
content/partials/pki-forwarding-bug.mdx:6:intended.  Furthermore, if a certificate is subsequently revoked on a performance secondary node, the secondary's 
content/partials/pki-forwarding-bug.mdx:9:Certificates issued after the fix are correctly stored locally to the performance secondary.

[cipherboy@lp10 website]$ gif 'Performance Replicat'
content/docs/release-notes/1.10.0.mdx:73:Vault’s [eventual consistency](/vault/docs/enterprise/consistency) model precludes read-after-write guarantees when clients interact with performance standbys or performance replication clusters. The [Client Controlled Consistency](/vault/docs/enterprise/consistency#vault-1-7-mitigations) mitigations supported with Vault 1.7 provide ways to achieve consistency through client modifications or by using the agent for proxied requests, which is not possible in all cases. The Server Side Consistent Tokens feature provides an implicit way to achieve consistency by embedding the minimum Write-Ahead-Log state information in the Service tokens returned from logins or token-create requests. This feature introduces changes in the token format and the new tokesn will be the default tokens starting in Vault 1.10.0. Vault 1.10.0 is backwards compatible with old tokens.

[cipherboy@lp10 website]$ gif 'performance primary'
content/docs/release-notes/1.5.0.mdx:26:- Updated DR and performance primary dashboards that include a list of known secondaries and their corresponding UI URLs (for easier context-switching between the UIs)

[cipherboy@lp10 website]$ gif 'managed.*keys'
content/api-docs/secret/pki.mdx:1805:be retrieved later_; if it is `kms`, a [managed keys](#managed-keys) will be
content/api-docs/secret/pki.mdx:1818:  keys](#managed-keys). This parameter is part of the request URL.
content/api-docs/secret/pki.mdx:1836:#### Managed keys parameters
content/api-docs/secret/pki.mdx:1838:See [Managed Keys](#managed-keys) for additional details on this feature, if
content/api-docs/secret/pki.mdx:1888:be reused for this root; if it is `kms`, a [managed keys](#managed-keys) will
content/api-docs/secret/pki.mdx:1914:  for more details about managed keys](#managed-keys). This parameter is part
content/api-docs/secret/pki.mdx:2046:#### Managed keys parameters
content/api-docs/secret/pki.mdx:2048:See [Managed Keys](#managed-keys) for additional details on this feature, if
content/api-docs/secret/pki.mdx:2128:  details](#managed-keys). This parameter is part of the request URL.
content/api-docs/secret/pki.mdx:2172:   This includes any managed keys.
content/api-docs/secret/pki.mdx:2242:#### Managed keys parameters
content/api-docs/secret/pki.mdx:2244:See [Managed Keys](#managed-keys) for additional details on this feature, if
content/api-docs/secret/pki.mdx:2526:   This most commonly needs to be modified when using PKCS#11 managed keys
content/api-docs/system/mounts.mdx:174:  - `allowed_managed_keys` `(array: [])` - List of managed key registry entry names
content/api-docs/system/mounts.mdx:367:- `allowed_managed_keys` `(array: [])` - List of managed key registry entry names
content/docs/commands/secrets/enable.mdx:106:- `-allowed-managed-keys` `(string: "")` - Managed key name(s) that the mount
content/docs/commands/secrets/tune.mdx:92:- `-allowed-managed-keys` `(string: "")` - Managed key name(s) that the mount
content/docs/release-notes/1.12.0.mdx:75:Managed Keys let Vault secrets engines (currently PKI) use keys stored in Cloud KMS systems for cryptographic operations like certificate signing.  Vault 1.12 adds support for GCP Cloud KMS to the Managed Key system, where previously AWS, Azure, and PKCS#11 Hardware Security Modules were supported.
content/docs/release-notes/1.13.0.mdx:50:- **Managed Keys in Transit Engine:** Support for offloading Transit Key
content/docs/secrets/pki/considerations.mdx:17:   - [Managed Keys](#managed-keys)
content/docs/secrets/pki/considerations.mdx:800:~> Note: With managed keys, operators might need access to [read the mount
content/docs/secrets/pki/considerations.mdx:802:   may need access [to use or manage managed keys](/vault/api-docs/system/managed-keys).
content/docs/secrets/gcp.mdx:595:- Infinite lifetime in GCP (i.e. if they are not managed properly, leaked keys can live forever)
content/docs/upgrading/upgrade-to-1.13.x.mdx:184:@include 'known-issues/transit-managed-keys-panics.mdx'
content/docs/upgrading/upgrade-to-1.14.x.mdx:50:@include 'known-issues/transit-managed-keys-panics.mdx'
content/docs/upgrading/upgrade-to-1.14.x.mdx:52:@include 'known-issues/transit-managed-keys-sign-fails.mdx'
content/partials/api/restricted-endpoints.mdx:32:`sys/managed-keys/*`                        | YES  | NO
content/partials/known-issues/transit-managed-keys-panics.mdx:1:### Transit Encryption with Cloud KMS managed keys causes a panic
content/partials/known-issues/transit-managed-keys-panics.mdx:16:- PKCS#11 managed keys
content/partials/known-issues/transit-managed-keys-sign-fails.mdx:1:### Transit Sign API calls with managed keys fail
content/partials/pki-double-migration-bug.mdx:16:The migration fails when Vault finds managed keys associated with the legacy

I think release notes and upgrading can perhaps be removed verbatim, but I'm curious your thoughts on leaving known issues intact.

[JanMa]

Thanks for double-checking @cipherboy. So far I left all upgrade docs and release notes untouched because i plan to remove them in a future PR. But I did miss the managed keys sections in some docs and removed them accordingly 👍

[joewxboy]

A few more things to remove I think:

Are we keeping a comprehensive list of what has been removed? I suspect we'll need it.

[cipherboy]

A few more things to remove I think:

Are we keeping a comprehensive list of what has been removed? I suspect we'll need it.

Note that these are removals by virtue of forking sans Enterprise. So mostly reducing references to Enterprise in the documentation, plus features which we know to be Enterprise only already.

The Enterprise code base lives in a separate, internal repo and thus we never had that code and needed to sync up code+docs removals. Upstream used the OSS repo's docs for both OSS + Enterprise.

I don't know that I see a quick, concise list of Enterprise-only features on HashiCorp's website though. For the most part, its things like Performance Replication, Disaster Recovery Replication, Seal Wrapping, Managed Keys, Namespaces, Auto-Snapshotting, and various other features which layer on top of the former (e.g., PKI has a cross-cluster CRL mentioned in these docs, necessitated by having performance replication -- the code is present under the MPL in OSS, but won't work and may not be necessary unless upstream's Enterprise clustering semantics are followed exactly)...

What we'll do with those stub features, I don't know.