One thing to keep in mind is that this sets the precedent for providers managing their own db "stuff". So while it may be rare for FAB, we should look at this from a general "provider with db stuff" perspective. And other use cases could have more frequent changes.
Overall I also think this strikes a good balance. If there is one thing I'm not 100% convinced on, it's the need for `airlflow db migrate/reset` to also do provider migrations - I feel we'd be okay with simply letting providers expose their own commands to do it without any true integration with core. But I also don't feel strongly enough to really suggest moving away from doing it, I just don't see it as required. tldr: +1 on separate db commands for providers, +0.25 on integrating with core db commands.
