It seems the client aborted the connection by sending an RST packet to
the server.

I found two ways to fix the problem.  One way is to set gnutls-log-level
to 1 (or higher).  The other is to set gnutls-algorithm-priority to
"NORMAL:-VERS-TLS1.3".

If you set gnutls-log-level to 1, you get some interesting output, but
unfortunately none of it describes the problem, since the problem
doesn't occur!  It's surprising that increasing the log level solves the
problem.

If you set gnutls-algorithm-priority to "NORMAL:-VERS-TLS1.3", my
understanding is that you are telling GnuTLS you don't want to use
version 1.3, and then (in my case) Gnus will connect successfully to
imap.gmail.com using TLS v1.2.  I verified that using Wireshark.

This feels similar (but maybe not identical) to the following issue:

http://emacs.1067599.n8.nabble.com/Emacs-gnus-tls-IMAP-connection-problems-with-Google-tp474191p475443.html

There, the author encountered a problem that prevented them from
connecting to a website using TLS v1.3.  They resolved it by setting
gnutls-algorithm-priority like I did, but they were not using Gnus.
Earlier in the same thread, another person reported the exact same issue
as me: they couldn't connect to imap.gmail.com using Gnus, and they also
discovered that the problem went away when they set gnutls-log-level to
2.

Separately, I've also heard that when GnuTLS added support for TLS v1.3,
they made some changes that require callers to change the way they call
GnuTLS.  For example, consider this:

https://nikmav.blogspot.com/2018/05/gnutls-and-tls-13.html

"Post handshake authentication

[...] In GnuTLS the implementation relies on a new non-fatal error code
which must be handled by the client application. [...]"

I don't know if post handshake authentication has anything to do with
the error I saw (I have no reason to believe that it does), but I
mention this because it makes me wonder if perhaps Gnus needs to be
updated to play nicely with GnuTLS' implementation of TLS v1.3.

Another possibility is that Gmail's IMAP server is misbehaving, but I
don't know if the evidence supports that conclusion at this time.

Thoughts?  I'm glad I have a work-around, but if there's anything I can
do to help resolve the actual problem, please let me know.

-- 
Chris