CSV: Add field to set userId & localpart

[nikzen]

Description

To migrate our remaining customers from LDAP to Zitadel, we need to reuse the localpart.

Solution

Add an extra field in the csv which is used to set the userId and localpart usermtadata.

[nikzen]

The CSV import uses surname, prename & mail as input. This works for new users. If we want to migrate existing users, we also need to define the localpart as otherwise the user will lose access to their account.

We should add another field which is called localpart. Based on this field we will add the localpart as usermetadata and we are also able to set the userId to this attribute. (https://zitadel.com/docs/apis/resources/user_service_v2/user-service-add-human-user)

curl -L 'https://$CUSTOM-DOMAIN/v2/users/human' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
--data-raw '{
  "userId": "localpart-value",
  },
  "profile": {
    "givenName": "Minnie",
    "familyName": "Mouse",
    "displayName": "Minnie Mouse"
  },
  "email": {
    "email": "[email protected]",
    },

  "metadata": [
    {
      "key": "localpart",
      "value": "localpart-value"
    }
  ],
}'

[tlater-famedly]

"userId": "localpart-value",

Hm, we have this problem in general, but since syncing requires knowing the original sources' ID we'll need to come up with some clever way to match user IDs if they don't match whatever database we sync from in the future (assuming a different sync method ends up being used after an initial CSV sync).

If this is a use case we care about, we could write yet another migration tool that updates user IDs according to a new source we migrate to, under the assumption that email addresses have not changed.

[emgrav]

For now we will reiterate and make even clearer that switching from one sync method to another is unsupported.

[jannden]

Don't confuse with #75

This task talks about zitadel user IDs while #75 talks about external user IDs.