Refine logging of database creation

[danielballan]

I like that #714 logs catalog creation, but I think ERROR-level logging is not quite right. I suspect the original thinking was, "We're capturing 'standard error', so log to 'error'." But you get effects like this which I think can create the wrong impression that something is broken:

tiled/_tests/test_access_control.py::test_service_principal_access 
-------------------------------------------------------- live log call ---------------------------------------------------------
2024-04-19 10:36:30 [   ERROR] Subprocess stderr: Database sqlite+aiosqlite:////tmp/pytest-of-dallan/pytest-80/test_service_principal_access0/catalog.db is new. Creating tables.
Database initialized.
 (adapter.py:1314)
2024-04-19 10:36:32 [   ERROR] Subprocess stderr:  (adapter.py:1314)
PASSED                                                              

Maybe we can change this to INFO-level logging. I am imagine @dylanmcreynolds will be happy as long as the log message is visible for his use case(s). Can you past in here the workflows where you want to see this log message, Dylan?

[dylanmcreynolds]

Yes, the intent was that we log the database creation in "info" while logging any errors seen in "error". This was a miss. As a user I can't imagine not wanting to see everything. If there are deployment processes that treat error differently from info, then we have to think really hard about how to do this.

The issue of having no logging at all has hit me a few times in container scenarios (usually messing up an environment variable for database settings that results in the database not initing...then when tiled starts up, it errors out because the database is not configured and there's no good indication that this is because the subprocess failed. I know that we need to be cautious of over-logging, but I think it's worth being slightly verbose on startup. I assigned this issue to myself.