JsonRpcConnection: don't write new messages on shutdown

[Al2Klimov]

In fact, this is already done for the outer loop (for each bulk), just not yet for the inner one (for each message of a bulk). So once the remote signals EOF, don't try to process the remaining queue until write error (which can't be associated with a particular message anyway, due to buffering), but just let the peer go. Flush already half-written messages, though, if possible.

• This is absolutely symmetrical to JsonRpcConnection: Don't read any data on shutdown #10213

closes #10216
closes #10219
closes #10220

[Al2Klimov]

• JsonRpcConnection: Don't drop client from cache prematurely #10210 is literally begging for this. :-)

[yhabteab]

• JsonRpcConnection: Don't drop client from cache prematurely #10210 is literally begging for this. :-)

You should carefully read the PR description. That PR has nothing to do with this! That PR fixes this bug #10210 (comment) with the last commit.

[Al2Klimov]

This PR indeed doesn't block anything. But yours is yet another argument for this.

[julianbrost]

this is already done for the outer loop (for each bulk), just not yet for the inner one (for each message of a bulk)

For me, that part is the most relevant part of the reasoning for this PR. When we say disconnect, it currently stops at an arbitrary point in the still queued messages (i.e. the random position where m_OutgoingMessagesQueue happened to be read last time by the write coroutine). If we say that calling disconnect does so early and discards messages, finishing the current message and then stopping makes sense.

But yours is yet another argument for this.

I don't really see how this relates to #10210. The remaining problem of that PR was that it waited for m_WriterDone without a timeout, so if the write routine (already) blocked in write or flush, it wait for a long time.

[Al2Klimov]

queue can get quite big, can't it? And your connection could be relatively slow. Fast enough that messages make it through, but slow enough to notice it. Now we have the choice:

• Stop early, so that no message/TLS is half-written (this PR)
• Try to get something through, risking being interrupted in the middle of a message

[julianbrost]

I'm not sure what this is trying to tell me. There's always the possibility that a connection dies somewhere in the middle of a message, so that can always happen. The one thing that would be strange would be to stop somewhere in the middle of a message but then send a TLS close notify (i.e. boost::asio:ssl::stream::async_shutdown() or SSL_shutdown()).