feat!(go): split Flight SQL into its own module

[lidavidm]

This way we don't leak CVEs/dependencies from the driver into the core ADBC package.

Breaking changes:

• package go/adbc/driver/flightsql => go/driver/flightsql
• package go/adbc/sqldriver/flightsql => go/driver/flightsql/sqldriver

TODOs

• CI, build
• Get OpenTelemetry (or at least the exporters) out of the core, too
• Regenerate licenses
• Update regenerate command in Makefile

Closes #4623.

[lidavidm]

I wonder if I should just move driverbase to be part of flightsql (since we don't really expect to export it anyways) to get the OpenTelemetry dependency out of core, or even use the thirdparty driverbase fork

[zeroshade]

I wonder if I should just move driverbase to be part of flightsql (since we don't really expect to export it anyways) to get the OpenTelemetry dependency out of core, or even use the thirdparty driverbase fork

I think that's fine since we have we have https://github.com/adbc-drivers/driverbase-go

[lidavidm]

Ah, but we still have panicdummy. Maybe the compromise can be go/adbc and go/drivers...

[lidavidm]

Alright, that gets gRPC entirely out of the core API...we still depend on the core/trace OTel packages, but they seem to have minimal dependencies, and we still have Protobuf due to some error metadata definitions, but that should also hopefully be OK.

[zeroshade]

You're going to need to update the release scripts to add a new tag when we do releases in addition to the go/adbc/vX.Y.Z tag. You'll need to separately also add go/driver/vX.Y.Z as a tag for releases

[lidavidm]

Hmm, how is this supposed to work with the go.mod override? Rust/Cargo handles this properly with workspaces, but I suppose for a release we need to remove the override and point at the new tag?

[lidavidm]

Ok, I think I'll go with using a Go workspace, and updating scripts/instructions so we auto-publish go/adbc, and then we need a second maintainer step to update and publish go/driver.

[lidavidm]

I think for now, I'm not gonna fiddle with go.work, although it means the Flight SQL driver technically uses older API definitions, but I think that's OK since we moved all the driver code anyways. Perhaps at some point we should consider splitting the Flight SQL driver into a separate Apache repository