If frames are received out of order (e.g. due to packet loss) on a
stopped stream, the local `end` might be less than the high water mark
`Recv::end`. The previous code would set `Assembler::bytes_read` to
that incorrect lower value, potentially after it had previously taken
a higher value.

If `MAX_STREAM_DATA` frames are then queued for that stream (e.g. due
to retransmits prompted by packet loss), we might attempt to transmit
a smaller flow control credit than we had previously. This would cause
an underflow in the subtraction used to judge whether an increase in
flow control credit is worth sending, and violates the spec besides.

Because additional data on a stopped stream isn't useful, there's no
benefit to updating stream-level flow control at all, so we might as
well remove that path entirely. Connection-level flow control is still
maintained at the StreamsState level based on change in the stream's
high-water mark or determination of the final offset.

We only queue MAX_STREAM_DATA when stream data is read by the
application, which never happens for stopped streams, but loss of
packets carrying previously sent MAX_STREAM_DATA frames could still
cause fresh ones to be queued unnecessarily. Filtering them out isn't
strictly necessary, but saves some space in the packet.