In the bbolt store, an empty config for a feature is represented as an
empty array, while in for the SQL store, the same config is represented
as nil. Therefore, in the scenario where a specific feature has an empty
config, we override the SQL FeatureConfig for that feature to also be
set to an empty array. This is needed to ensure that the deep equals
check in the migration validation does not fail in this scenario.
If a user creates a session linked to an account, but later deletes that
account using the `litcli accounts remove` command, the KVDB session
will still contain the account ID of the removed account.
During the KVDB to SQL migration, the accounts migration runs before the
sessions migration. Since the deleted account no longer exists, it
cannot be migrated. As a result, the migrated SQL session cannot link to
the now non-existent account in the SQL store.
In such cases, we will migrate the session and not link to any account
in the SQL session.
The logic to avoid duplicate session IDs was first added with the
session linking linking functionality. That means that there may be old
legacy sessions that were added prior to that which may have duplicate
IDs. Before this commit, such sessions would cause the kvdb to SQL
migration to error, as there is a uniqueness constraint on the legacy
session alias in the SQL sessions table.
We want to keep that constraint, so in such rare cases, we update the
kvdb to SQL migration logic to drop all but the session with the
latest CreatedAt time if for sessions that share the same ID.
That follows the logic in c8b78bd10d as
closely as possible, as that migration ensured that all sessions but the
latest one was revoked if multiple sessions shared the same ID.
Similar to the previous commit, we also sort the
`MacaroonRecipe.Permissions` slice to ensure it can be compared in a
deterministic manner during migrations.
In the kvdb to sql migration, if there have been caveats set for the
MacaroonRecipe, the order of the postgres db caveats will in very rare
cases differ from the kv store caveats. Therefore, we sort both the kv
and sql caveats by their ID, so that we can compare them in a
deterministic way.
This commit introduces the migration logic for transitioning the
sessions store from kvdb to SQL.
Note that as of this commit, the migration is not yet triggered by any
production code, i.e. only tests execute the migration logic.
