Migrate: Refactor for migration improvements #2448
Description
Checklist
- I agree to the terms within the OpenFGA Code of Conduct.
Describe the problem you'd like to have solved
We need to make migrations of openFGA smoother for applications in production. We currently rely on goose's global registry + default provider for our migrations.
This can be done in multiple steps:
- First it would be good to move the per-database code out into the individual drivers.
- Have users inject their migration package for running their own migration schema without relying on goose
Describe the ideal solution
It'd be nice to eventually switch away from them and be able to inject each own migration satisfying an interface.
Alternatives and current workarounds
No response
Additional context
This is a follow up to: #2442