[chttp2] fix stream leak with queued flow control update and absence of writes

[apolcyn]

As discovered with internal issue b/242712384, there's a leak that can happen as follows:

1. Client RPC closes writes, e.g. calls WritesDone()
2. Client attempts to read a message and trailers, and receives trailers only.

Since writes are closed first, chttp2 will call grpc_chttp2_mark_stream_closed with close_reads=1, during 2). This can cause remove_stream to be called before updating flow control and taking a new ref on the stream.

In my repro of b/242712384, I observed this last stream flow control update to always have queuing urgency. In this case, nothing is guaranteed to initiate further writes on the transport (and the RPC has completed as far as the application is concerned). So even after the application destroys the channel and fully unrefs the RPC, the ref held by the queued flow control update will keep the stream and connection objects alive indefinitely.

---

Edit:

Since #30550 submitted, the above description doesn't actually repro because of the change to StreamFlowControl::UpdateAction. But the same underlying bug can also repro in a different way, which is what the test is now based off of:

1. server sends a message and status

2. client polls the connection, reads message and status off the wire and marks the stream closed, without having yet started a RECV_MESSAGE or RECV_STATUS op

3. client performs RECV_MESSAGE and RECV_STATUS ops, which complete immediately. But the stream flow control update is queued and not flushed out because we already had all the data and didn't need to send any pre-emptive updates.