Replace successful_posthandshake_op with successful_read_op

Turns out the current code to guess whether to return
G_TLS_ERROR_CERTIFICATE_REQUIRED is racy. With TLS 1.2, the client would
see a handshake failure if a client certificate was required but not
provided (or not accepted). That's no longer the case with TLS 1.3;
instead, the client will see a successful handshake before it sees the
server close the connection. GnuTLS is no longer able to indicate *why*
the connection was closed unless the server sends
GNUTLS_A_CERTIFICATE_REQUIRED, but we don't support alerts yet, #65. In
the meantime, we're stuck using a heuristic to decide whether to return
G_TLS_ERROR_CERTIFICATE_REQUIRED: if the server requested a certificate,
and we did not provide one, and an operation fails, and we have never
successfully done any operation after the handshake, then assume the
server rejected our certificate and return
G_TLS_ERROR_CERTIFICATE_REQUIRED. This behavior was added in 14be4745.

However, there in a window of time during which the client may see write
operations succeed even though it failed to provide an acceptable
certificate and the connection is about to be closed by the server. If a
write succeeds, then our heuristic to decide whether to return
G_TLS_ERROR_CERTIFICATE_REQUIRED fails. So let's change the heuristic to
check only for reads instead. A read can never succeed because a
properly-implemented server would not write any data before it verifies
that the client certificate is acceptable.

This commit fixes 14be4745. It's sort of covered by existing tests, in
that we have tests that check for G_TLS_ERROR_CERTIFICATE_REQUIRED,
although they don't seem to be tripping this race. We have a libsoup
test /ssl/tls-interaction that is really hitting this race, although
this change won't be enough to fix that test, because that test needs to
be changed to no longer expect the TLS 1.2 behavior.