Remove "Migration pre 1.5.1" in docs

The Seal/Unseal page in the web docs contains a section with the header
"Migration pre 1.5.1". This is referring to Vault; OpenBao's versioning
is not yet decided but in any case it does not need to carry around docs
for legacy versions of Vault.

Signed-off-by: John Arnold <[email protected]>

website/content/docs/concepts/seal.mdx

@@ -265,56 +265,3 @@ any storage backend.
 1. At this point, configuration files of all the nodes can be updated to only have the
  new seal information. Standby nodes can be restarted right away and the active
  node can be restarted upon a leadership change.
-
-### Migration pre 1.5.1
-
-#### Migration from shamir to auto unseal
-
-To migrate from Shamir keys to Auto Unseal, take your server cluster offline and
-update the [seal configuration](/docs/configuration/seal) with the appropriate
-seal configuration. Bring your server back up and leave the rest of the nodes
-offline if using multi-server mode, then run the unseal process with the
-`-migrate` flag and bring the rest of the cluster online.
-
-All unseal commands must specify the `-migrate` flag. Once the required
-threshold of unseal keys are entered, unseal keys will be migrated to recovery
-keys.
-
-`$ bao operator unseal -migrate`
-
-#### Migration from auto unseal to shamir
-
-To migrate from Auto Unseal to Shamir keys, take your server cluster offline
-and update the [seal configuration](/docs/configuration/seal) and add `disabled
-= "true"` to the seal block. This allows the migration to use this information
-to decrypt the key but will not unseal OpenBao. When you bring your server back
-up, run the unseal process with the `-migrate` flag and use the Recovery Keys
-to perform the migration. All unseal commands must specify the `-migrate` flag.
-Once the required threshold of recovery keys are entered, the recovery keys
-will be migrated to be used as unseal keys.
-
-#### Migration from auto unseal to auto unseal
-
-To migrate from Auto Unseal to a different Auto Unseal configuration, take your
-server cluster offline and update the existing [seal
-configuration](/docs/configuration/seal) and add `disabled = "true"` to the seal
-block. Then add another seal block to describe the new seal.
-
-When you bring your server back up, run the unseal process with the `-migrate`
-flag and use the Recovery Keys to perform the migration. All unseal commands
-must specify the `-migrate` flag. Once the required threshold of recovery keys
-are entered, the recovery keys will be kept and used as recovery keys in the new
-seal.
-
-#### Migration with integrated storage
-
-Integrated Storage uses the Raft protocol underneath, which requires a quorum of
-servers to be online before the cluster is functional. Therefore, bringing the
-cluster back up one node at a time with the seal configuration updated, will not
-work in this case. Follow the same steps for each kind of migration described
-above with the exception that after the cluster is taken offline, update the
-seal configurations of all the nodes appropriately and bring them all back up.
-When the quorum of nodes are back up, Raft will elect a leader and the leader
-node that will perform the migration. The migrated information will be replicated to
-all other cluster peers and when the peers eventually become the leader,
-migration will not happen again on the peer nodes.