[db] Access DB via connections, not via pool

[smklein]

• Accesses the DB via connections explicitly, rather than using a pool
• This change reduces generics slightly, and simplifies error handling. Callers can deal with "pool errors" when checking out the connection, and can deal with "query errors" separately when issuing the queries themselves.

Depends on oxidecomputer/async-bb8-diesel#52
Fixes #4132

[davepacheco]

I agree this is a cleaner interface. I reviewed the datastore/mod.rs, error.rs, and a few other areas, but I did not review most of nexus/db-queries/src/db because there's so much delta here that's mechanical but non-trivial.

[davepacheco]

Thanks for doing this!

[smklein]

I ran the following command:

cargo build -p omicron-nexus && touch nexus/src/lib.rs  && cargo build -p omicron-nexus --timings

(AKA, do a clean build, touch one file, rebuild validating timings).

This is what I saw on my Linux laptop on main:

This is what I saw with this PR:

I'm surprised by this result, and think I might need to do a deep dive into why this is happening.

[smklein]

Huh, well, that's... interesting. I tried using https://blog.rust-lang.org/inside-rust/2020/02/25/intro-rustc-self-profile.html to dig into "why did this make the build slower", and here's what I found:

I basically wanted to run cargo rustc -- -Zself-profile -Zself-profile-events=default,args , but doing to caused rustc to ICE, so I just queries the default events, and things seemed to work. Note: Running these commands required nightly, and I used:

 $ rustup run nightly rustc --version
rustc 1.74.0-nightly (e7c502d93 2023-09-27)

I ran the following command:

cargo +nightly rustc -p omicron-nexus --lib && touch nexus/src/lib.rs && cargo +nightly rustc -p omicron-nexus --lib -- -Zself-profile -Zself-profile-events=default

(just like before -- build, touch one file, rebuild)

I ran this on both main and this branch. Comparing these results, I was not able to reproduce this PR building slower -- it was actually a small improvement over main!

Since I was forced to use the nightly compiler, I figured I'd redo the build --timings comparison too. Here are the results, using the rustc 1.74.0-nightly (e7c502d93 2023-09-27) toolchain:

main

This PR

My takeaway

I think this PR is safe to land? It seems that the issues causing build speeds to regress are more related to our rust version than the commit itself.

[davepacheco]

In case it's helpful for anybody else, I had a branch with changes that needed to be updated after merging with this change and this worked to update my branch:

• replace calls to public_error_from_diesel_pool() with public_error_from_diesel()
• replace calls to pool_authorized() with calls to pool_connection_authorized()
• replace use of TransactionError::Pool with TransactionError::Connection