Pipeline rewrite

[jtv]

Nowadays libpq has a "pipeline" feature (inspired by the Java driver, where I guess it was introduced because JDBC supported it because ODBC had it). But libpqxx has had one for 20 years (inspired by a lecture on CPU performance features).

Amazingly, the two designs came out very similar in their essentials!

So I've been wanting to try and rewrite the pqxx::pipeline class based on this libpq feature, at least when building with libpq 14 or better. (Oldest supported version is currently 13).

[jtv]

Update: I intend to prototype this change in 8.0, but not release it. Instead, I'll use the process to see what incompatible API changes are needed. I'll then deprecate items as needed in 8.0, but leave the final implementation (along with its API changes) for 9.0.

And who knows, by that time it may no longer be necessary to support libpq versions without the pipelining version!

[jtv]

I've tried some of this, but a lot more needs to be done and I'm not feeling too well. However some concepts are starting to form. I don't see anything in the API as yet that I need to deprecate in 8.0. However the class will most likely need a complete rewrite.

Also there's a new feature that can probably wait: whereas the existing pipeline class lives within a transaction, with the libpq support it makes more sense to allow transactions within pipelines. That may require major surgery to the transaction hierarchy though, since the pipeline would sit between the connection and the transaction, rather than below the transaction. Executing queries works very differently. It might make sense to have a special transaction class for inside a pipeline, but then does that also mean we want subtransactions inside pipelines? If so... they could nest inside a transaction inside the pipeline or inside a transaction outside the pipeline. (Either of which could in turn be a subtransaction, one of which could be of either kind.)

Perhaps we should keep things simple, to stop them from getting out of control. It's going to take a lot of work just to keep error handling correct, especially when it comes to recovery.