Move database revision tags to separate file

[guerler]

This change moves REVISION_TAGS into a constant-only dbrevisions.py file, simplifying maintenance.

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[jdavcs]

REVISION_TAGS is just a Python constant; it's not a configuration option that can take on different values. We only update it by adding a new tag each release, we never edit or delete: you would never, ever want to change any of those hashes. I wouldn't store this in a yaml file.

[guerler]

I see your point. The goal is not to suggest configurability, but to separate static release data from code. Right now release managers must edit a code file with logic just to add a new tag. Moving this into a data-only file avoids that. If YAML feels misleading, we could use a dbrevisions.json file instead. A minimal dbrevisions.py with just a dict would also work, but YAML or JSON seem clearer.

[mvdbeek]

Every time we load stuff from disk in the module namespace we slow down the startup process. I'm with @jdavcs on this one. You can also validate that the head revision is listed in the migration tests for instance so bumping this would be up to whoever adds a migration.

[guerler]

Thanks for the review and suggestions. Does this look ok now @jdavcs?

[jdavcs]

Looks good, thank you!