Non system schema instantiation in `replica::distributed_loader::init_non_system_keyspaces` access tablets managed by group0, but a node may have crashed in the middle of raft command application and those tables may be inconsistent (there is no atomicity guaranty while a command is been applied. Fix that by moving existing group0 initialization before the call to `replica::distributed_loader::init_non_system_keyspaces`. The in memory state machine enablement stays in the same place since loading of a state machine into memory depends on schema already be instantiated into memory.
No need to backport since this does not fix any known bug. In fact migration manager (the component that group0 state machine uses to manage schema tables) is careful to make sure all schema mutations are in the same commitlog segment, so they will be seen as applied atomically, but the bug may happen with dependencies between schema and other components managed by group0 like topology.
Closesscylladb/scylladb#30207
* github.com:scylladb/scylladb:
main: replay group0 raft log before loading non-system keyspaces
raft: separate group0 server start from in-memory state machine enablement
1ba995653e