Ignore already removed deallocated prepared statement headers

[mdesmet]

Description

Resolves #248

X-Trino-Deallocated-Prepare may appear on multiple responses. Query execution should not fail on prepared statement removal if the prepared statement has already been removed.

Release notes

( ) This is not user-visible or docs only and no release notes are required.
( ) Release notes are required, please propose a release note for me.
(x) Release notes are required, with the following suggested text:

* Fix failure on already removed deallocated prepared statement headers

[hashhar]

LGTM. @findepi is the server supposed to be doing this?

[findepi]

is the server supposed to be doing this?

i don't think it is.

from the issue

Steps To Reproduce
I wasn't able to reproduce this locally, only in CI. So I assume some type of race condition is happening.

this is concerning a bit. the client protocol is "single threaded", i.e. there is typically exactly one ongoing request.

[hashhar]

Can we add a debug log or a warnings.warn here since ideally this should not be happenning at all. We should try to collect when this happens and why and fix it.

[hashhar]

Useful information to log would be the statement we are trying to deallocate, the current state of the prepared_statements dict and the response headers we received.

[mdesmet]

@hashhar : An alternative solution would be to implement the deallocated prepared statements as a set instead and merge them when performing a request (as in the JDBC driver). The way it's done in JDBC makes me think that this behaviour might actually not be erroneous but I'm still investigating if this is the case or not.