OIDC to Stytch migration

[patrislav]

This adds 3 pieces required to perform account migrations. Please note that a "migration" in this context does not involve removing the original account or making it unavailable by any means. Instead the migration process -- when completed -- simply enables clients to sign in users using either the original or "migrated" account created in the migration process. Thanks to this, clients may update to using the new system at their own pace.

1. Hook in the RegisterSession intent handler that continuously migrates any accounts that match the config. This is what enables the clients the freedom to update at any time as accounts will continue to be migrated even after the initial batch manual migration is complete.
2. NextMigrationBatch returns the next paginated batch of accounts identifiers that need to be migrated.
3. ProcessMigrationBatch creates the new accounts for the specified batch of account identifiers.

The last two require the admin level JWT as access control. However, other than being relatively resource-intensive, these are non-destructive and idempotent, as long as the config is correct. The manual process is equivalent to the automatic hooks except being used on all accounts.

[pkieltyka]

for migration names, what do you think if we prefix by a number?

for example update the code to..

enum Migration: string
  - 001_ OIDCToStytch

then for the Email migration in the other PR we have - 002_ OIDCToEmail .. and we will always ensure migrations run in order. However, maybe its not necessary as they don't necessarily have a dependency on eachother

[patrislav]

There's no dependency between migrations, they're intended to be idempotent and be runnable in any order.

Also is this a webrpc specific syntax? Wouldn't this not work anyway because of the generated names starting with numbers?

[pkieltyka]

if there is no requirement for order of migrations, then there probably isn't any value to this as with typical migrations like in RDMBS'

as for starting with a number, if that is problem, could always prefix with a letter like, "M001_XXX" .. but doesn't sound like we need this. The idea of migration numbers is that you record which migrations have been run, so they don't get triggered again once they are run, which, we may want to do in fact..

[patrislav]

In the case of authenticator migrations, each of them is idempotent so there's no risk in triggering them multiple times