[Controller] Consider skipping migrations unless GitLab version has changed

Summary

RE: discussion: (+5 comments)

> Mitch: Open question: now that we only run separated pre- and post-migrations when we are upgrading between versions, should we go ahead and _not_ run any migrations when we are _not_ upgrading between versions?

> Jason: The migrations job within the same version is effectively idempotent, but does consume time. We may just need to handle the situation where migrations need to be triggered again after a database connection is fixed / restored /..

As of !217 (merged), if the GitLab version is not changing, then all (pre and post) migrations run together. Theoretically, we could skip migrations in this scenario and only run them when the GitLab version is changing.

However, to Jason's point above, we'd need to consider if special situations preclude us from doing this.

Acceptance criteria

• Conclude whether it is safe to skip migrations when GitLab version is not changing
• If it is not safe, attempt to identify any potential checks we could write that would allow the Controller to take the special situations into account