Use correct repo for initial version check

Use the actual repo for the initial version check of the db version when
performing `db_sync --check`. Previously we always used the Legacy Repo
as the repo path was not populated in the `get_init_version` function.

This allowed the case where the new expand/contract/migrate repos
matched the legacy repo version number, the `db_sync --check` command
would assume that everything was properly up to date regardless of the
version for the expand/contract/migrate repositories. This was most
noticable in the case of a db not under version control.

Change-Id: Id5e6f74a5ed96fdf17e2c241466897974aa5a218
closes-bug: #1844157

keystone/common/sql/upgrades.py

@@ -231,8 +231,9 @@ def offline_sync_database_to_version(version=None):
 
 def get_db_version(repo=LEGACY_REPO):
     with sql.session_for_read() as session:
+        repo = find_repo(repo)
         return migration.db_version(
-            session.get_bind(), find_repo(repo), get_init_version())
+            session.get_bind(), repo, get_init_version(repo))
 
 
 def validate_upgrade_order(repo_name, target_repo_version=None):

releasenotes/notes/bug-1844157-7808af9bcea0429d.yaml

@@ -0,0 +1,13 @@
+---
+fixes:
+  - >
+    [`bug 1844157 <https://bugs.launchpad.net/keystone/+bug/1844157>`_]
+    When performing `keystone-manage db_sync --check` if the legacy repo
+    started at the same version number as the expand/contract/migrate
+    repos the check to see if the db was under version control failed
+    indicating that the db was up-to-date. This was due to the function
+    `get_init_version` never receiving the path for the repo queried for
+    version information. The fix is to ensure the repo path is always
+    passed to get_init_version from the
+    `keystone.common.sql.upgrade.get_db_version` function.
+