Correct microcluster schema migration order

[louiseschmidtgen]

Description

Migrations should be applied in the correct order with the latest migration being applied last.
Microcluster counts the migrations we have done.

Changing the order can lead to mistakes:
We previously apply schemaApplyMigration("feature-status", "000-feature-status.sql") at schema count 5, then we add in schemaApplyMigration("worker-tokens", "001-add-expiry.sql") at schema count 5, leading us to re-apply feature-status in count 6 when migrating the schema.

For instance, this issue occurred migrating moonray: https://github.com/canonical/k8s-snap/blob/archive/release-1.30-moonray/src/k8s/pkg/k8sd/database/schema.go

[HomayoonAlimohammadi]

I think the ordering matters on the table scope right? e.g. the 001-add-expiry.sql for worker-tokens should be after the 000-create.sql for the same table which it is.
the 001 here only refers to the worker-token table counter. the 000-feature-status.sql is not related to worker-token table so the ordering of feature-status related migrations should not matter with regards to the worker-token migrations. wdyt?

I might be totally wrong, but if this is the case, I would personally prefer to have the pseudo "grouping" that we already have with the tables being separated by new lines.

[louiseschmidtgen]

I think there is an issue with how microcluster applies these migrations here: https://github.com/canonical/microcluster/blob/v3/internal/db/update/schema.go#L266. MC seems to iterate over the latest migrations so if we change the order of the migrations we run into trouble.

[bschimke95]

Yes,looking at the code, the order seems important. @HomayoonAlimohammadi the grouping aspect was the reason why I put the 001-add-expiry.sql in that location. Seems like this was not a good idea :)

[HomayoonAlimohammadi]

Thanks a lot @louiseschmidtgen! left a minor comment of out curiosity

[bschimke95]

LGTM, nice catch