feat: allow for tests over flightsql

[universalmind303]

closes #2234

There's still a bit of cleanup to do, but it seems to work.

I'm planning on refactoring the test suites a bit, currently they always spin up a pg instance, which is not needed at all for the flightsql tests.

My plan is to refactor them so the following commands are accepted

> just slt 'path/to/test' # default pg behavior
> just slt 'path/to/test' --protocol=rpc # equivalent to the current `just slt 'path/to/test' --rpc-test`
> just slt 'path/to/test' --protocol=flightsql # run the tests over the flightsql wire protocol
> just slt 'path/to/test' --protocol=postgres # run the tests over the postgres wire protocol. (same as the default)

---

12/12 updates.

There are a few additional changes to the following files that I introduced in this PR worth highlighting.

crates/sqlexec/src/session.rs

• rename a few methods to make the intent clearer
• add a few new helper methods for the flightsql client

crates/glaredb/src/server.rs
There were some bigger changes in here, namely to ComputeServer. To make the tests easier to run in isolation (pg/rpc/flightsql), I decided to refactor the compute server a bit to make the postgres server optional.

Previously, we would always start up a postgres instance, now it is fully optional. You can specify what protocols you want to be exposed -- TODO: cleanup the cli args for this --

---

12/12 updates pt 2.

This PR really got away from me.. A lot bigger than I had originally anticipated. sorry reviewers

Updated the CLI args to allow for postgres to be optional. Just to be safe, I added a bunch of additional tests to make sure nothing broke in the process. So there are some changes to the cli args to handle the new functionality.

The only breaking change is to how you run the tests. just slt 'path/to/test' --protocol=rpc instead of just slt 'path/to/test' --rpc-test.

[tychoish]

seems great. would think that the package upgrades should probably be handled as workspace packages.

[scsmithr]

What does this do?

[universalmind303]

I can revert this as it's not really relevant to this PR, Just something i found while testing to make sure i didnt break any of the flags.

Clap has builtin macros for mutually exclusive arguments that we were previously checking manually. They give much nicer error messages, so i decided to throw this in here.

[scsmithr]

Previously, we would always start up a postgres instance [...]

We should make sure to be clear what we mean by this. We're starting up a server implementing the pg protocol. By saying "postgres instance", that can lead to confusion as we're not starting up a postgres instance.

[universalmind303]

Previously, we would always start up a postgres instance [...]

We should make sure to be clear what we mean by this. We're starting up a server implementing the pg protocol. By saying "postgres instance", that can lead to confusion as we're not starting up a postgres instance.

yeah sorry, i meant a postgres compatible api here.