[meta] Replace hook_schema() implementations with ::ensureTableExists()

Only one issue left in summary, probably could be closed

I think we need more child issues, there is sill the following hook_schema() implementations in core:

layout_build_schema()
search_schema()
user_schema()
node_schema()
locale_schema()
ban_schema()
help_topics_schema()
forum_schema()
book_schema()
history_schema()
tracker_schema()
dblog_schema()
shortcut_schema()
comment_schema()
file_schema()
workspaces_schema()

Some of these modules are slated for removal so it might be more efficient for us to deprecate the modules rather than refactoring, but several aren't.

help topics will be moved to help but that's for purpose of search

comment statistics IIRC there's ✨ Redo CommentStatisticsInterface Needs work
the same is for history and taxonomy

So yep, makes sense to keep

Added the list to the issue summary.

I've started on 📌 Replace ban_schema() implementation with ::ensureTableExists() Needs work .

It would be great to get some help on this one and then we have a template on how to approach the others. I need a little support to understand how to hook up the process to delete the table once the module is uninstalled.

I reached out for some support on slack regarding an approach to tear down tables when modules are uninstalled. This process needs to be clearer before we progress. The current implementations of this approach have all been for core services so we don't need to support tear down. This is obviously a necessity for any implementations within a module.

Hat tip: @berdir (for your support on slack)

Update from @catch on slack:

You can drop the tables on uninstall. In ModuleInstaller, it calls removeBin when a module providing a cache bin is uninstalled, and the database backend drops the table in ::removeBin()

Opened 📌 Implement lazy database creation for sessions Active

The ban module change is ready.

I have to say wrapping every call in an ensure table exists feels really cumbersome do we think 📌 Move the on-demand-table creation into the database API Needs work makes this transparent?

Is probably better to resolve that first then.