chore: move slt runner into main binary

[tychoish]

Addresses #2378

See discussion on the ticket.

[universalmind303]

I won't be a blocker for this, but I'd still much prefer feature flagging instead of just hiding. While the extra binary size isn't a lot, every little bit slowly adds up.

Since it is exclusively a development feature, it seems natural to feature flag as such.

[tychoish]

I won't be a blocker for this, but I'd still much prefer feature flagging instead of just hiding. While the extra binary size isn't a lot, every little bit slowly adds up.

by my read this shouldn't increase the binary by more than a few kb

Since it is exclusively a development feature, it seems natural to feature flag as such.

let's get it working first 😂 and talk about it on friday.

[tychoish]

Sorry for the really noisy PR, I've been trying to iron and and do a bit of cleanup with the dependencies just in awareness of the binary size. My conclusion generally:

• it's probably the flightsql client (this is the main thing that's in slt that wasn't in glaredb before.
• we might get more out of doing some flightsql RPC tests using a non-rust client (because testing it with go or python might reveal something tonic-specific that we've done, that the existing tests wouldn't catch.)
• the flightsql client will become moot when we start using flightsql as our internal IPC for dist exec anyway, so it's not super important now.
• we can always flag this out of the build later if we want, but I'd like to start with giving it a try.
• I think the most compelling argument for keeping this in main is that it means we can build glaredb for aarch64 and then run the SLTs with the binary from the package on the actual hardware, rather than just trusting that all of the cross compilation works.

Do folks agree?