Provide a way to migrate from one spiffeId to another

[lukidzi]

Description

While working on the migration from mesh.mTLS to MeshIdentity, I discovered an issue with transitioning from one SPIFFE ID to another.

Let’s assume we have two zones: zone-client and zone-server. A client runs in zone-client, and a server runs in zone-server.

1. Both zone-client and zone-server use mesh.mTLS, and the MeshService identity is based on kuma.io/service.
2. Both zones switch to MeshIdentity.
3. The client in zone-client can no longer communicate with the server in zone-server.
4. The MeshService of the server in zone-server is updated with a SPIFFE ID.
5. That MeshService is synced to zone-client.
6. The client’s configuration is updated with a SAN based on the new SPIFFE ID.
7. Traffic resumes and works correctly.

This illustrates a case where both zones begin using the new identity, but the server presents itself as spiffe://domain.zone-server.mesh.local/ns/server/sa/server while the client cannot yet verify this SAN, since the corresponding MeshService update has not propagated.

[lahabana]

Such a design will need a MADR