Reword or remove "Acquiring new ... connection" logline

[jtcohen6]

Describe the feature

This line of code confuses a lot of folks because it's logged to logs/dbt.log:

https://github.com/fishtown-analytics/dbt/blob/ec0f3d22e792127e9c2c709f369e1faf8eb13c8d/core/dbt/adapters/base/connections.py#L138-L139

As worded, it's pretty misleading! I'm also not convinced it's accurate: it's logged by commands that don't strictly need database connections (e.g. dbt ls, dbt parse). This is relevant to our thinking around formally separating project parsing from compilation/execution, as a step that requires minimal adapter-specific logic and does not require a database (or Internet) connection.

Why fix?

This leads folks to think that:

• dbt is opening dozens/hundreds of concurrent connections against their database
• The slowness of project parsing is due to opening and closing these connections

This has cropped up in #2948, #3135, and several Slack threads, to name a few.

History

As best as I can tell, the reason for having it seems to be that, during project parsing, we may need an adapter connection, though I can't think of when/why we would:

https://github.com/fishtown-analytics/dbt/blob/344a14416d22f0cfbeb56b9904092c8a4f38b1fc/core/dbt/parser/base.py#L279-L289

Looking through older commits, it seems like we envisioned a future where this wouldn't be necessary. I'm not sure why it is necessary today.

https://github.com/fishtown-analytics/dbt/blob/b8febddad5f16e1cd02be8d8a00b3e8effb0e105/core/dbt/context/providers.py#L686-L699

[github-actions]

This issue has been marked as Stale because it has been open for 180 days with no activity. If you would like the issue to remain open, please remove the stale label or comment on the issue, or it will be closed in 7 days.

[jtcohen6]

I'd still like to fix this one. I think it could be a very quick quality-of-life improvement.

[leahwicz]

@jtcohen6 would it make sense to do this with the structured logging work?

[jtcohen6]

@leahwicz I think the issue here is that we're actually calling a whole connection method we simply don't need at parse time. The logging is a symptom of that.

There are many other times later on that we call the same method, with the same logging, and it makes sense to keep those around.

I took a stab at removing that with call entirely in #4062, and tests seem to be passing...