Implement new protocol testing framework; start fixing flush

[1st1]

Please review the commits individually.

@tailhook The second commit that fixes Flush is the one relevant for the rust protocol implementation. Note that it only addresses #1107 partially.

[tailhook]

@tailhook The second commit that fixes Flush is the one relevant for the rust protocol implementation. Note that it only addresses #1107 partially.

I'm still not sure if this is enough to use flush flawlessly.

[1st1]

I'm still not sure if this is enough to use flush flawlessly.

Paul, can you elaborate please? It would also help if you could remind me why we want to send Flush to Postgres -- I can't think of a scenario where this is actually useful.

[tailhook]

I'm still not sure if this is enough to use flush flawlessly.

Paul, can you elaborate please?

Still don't recall and had no time to experiment with it. The concern is probably cherry-picking Sync messages here and there (and if we check for sync, why we don't check for flush in the same places?), but no known real use-case yet.

It would also help if you could remind me why we want to send Flush to Postgres -- I can't think of a scenario where this is actually useful.

I didn't propose and didn't support this change in any way. You have mentioned this as you expected it be like that all the time. If we can send a request to postgres and receive data without sync, we don't need to forward flush to postgres (I don't thing I'll do that in repl, but the documentation looks like it should work).

[1st1]

The concern is probably cherry-picking Sync messages here and there (and if we check for sync, why we don't check for flush in the same places?)

Well, the implementation should work along these lines:

• A user types SELECT 1; [ENTER]
• REPL sends {PREPARE} SELECT 1; {FLUSH}
• If an error occurs we display it to the user and REPL sends {SYNC}
• no error - REPL sends {EXECUTE}; {SYNC}

I didn't propose and didn't support this change in any way. ... If we can send a request to postgres and receive data without sync, we don't need to forward flush to postgres

Fair enough. We tightly control all messaging with Postgres and issue {FLUSH} ourselves when necessary. So I think we're good.