In the restore procedure, we upsert a new shard identity document. If we are restoring to a brand new cluster (as opposed to restoring the same cluster), we must use a newly generated clusterId in the document. The clusterId in the shard identity document needs to match the clusterId in the config.version document on config servers in the cluster.

Today, when we upsert a shard identity document in magic restore, we don't update the config.version document on config servers at all. Cloud may give magic restore a new clusterId in the shard identity document, leading to a mismatch in the cluster. Since config servers don't have shard identity documents (in a non-config shard deployment), we'll need to pass in the new (optional) clusterId via the restore configuration. We should do the following:

• If restoring a config server here, and the restore configuration has a clusterId field present, we should update the config.version document's clusterId to this value.
• We should add a targeted test case where we restore a "new cluster", and pass in new clusterIds and shard identity documents to the set.
• We should only allow this parameter (clusterId) in the restore configuration for config servers.
• It would be preferable to have a way to ensure the new clusterId in the config server is the same as the clusterId in the new shard identity documents, but this validation likely falls on the caller (Cloud), as magic restore is per-node and has no notion of cluster-wide restore settings.