An operation is rejected iff it has to be dropped before we can find an
upstream for it (unless we handle it ourselves, that is). At that point
it is failed unless completed successfully.

This makes a difference for multi-stage binds which alternate between
'failed' (we are waiting on a server response) and 'completed' (server
did what we asked them to, waiting on client to continue).

During response processing, an upstream connection could be marked ready
after a different bind had already been allocated to it, thus allowing
two binds to be in progress on the same connection.

Ondřej Kuzník authored Jan 16, 2018 and Ondřej Kuzník committed Nov 17, 2020

For a new bind request, this is obvious, for SASL bind requests, we do
not know the final identity until we have finished handling it, make
sure it stays empty until then.

Ondřej Kuzník authored Dec 13, 2017 and Ondřej Kuzník committed Nov 17, 2020

Will only try to extract the TLS client certificate name if used during
the last handshake.

Ondřej Kuzník authored Dec 13, 2017 and Ondřej Kuzník committed Nov 17, 2020

Introduces pinned operations. When SASL bind finishes, we might still
have to maintain a link between the client an an upstream for future
bind operations if we got a SASL Bind in Progress result code. We zero
out the msgids and remember a server-unique identifer on the client and
the relevant operation that lets us retrieve that link again. This
operation is reclaimed just like anything else when connections drop.

Hopefully, this should work for LDAP TXN and VC Exop support with SASL
later as well since it allows for many-to-many links to exist.

Ondřej Kuzník authored Dec 13, 2017 and Ondřej Kuzník committed Nov 17, 2020

We have to do most of out processing before we send the request over to
the upstream. If we don't, we might be too late and the response might
have arrived already.