Final DATA frames

One other change to draw the working groups' attention to, on the opposite end of the stream from initial PRIORITY frames:

Issue #1885<https://github.com/quicwg/base-drafts/issues/1885> points out that, as in HTTP/2, it is inefficient to have to length-prefix each chunk of a response which is being generated incrementally.  In H2, this is unavoidable, because the frames are also the unit of multiplexing.  In H3, the QUIC STREAM frames are always length-prefixed, but we can have very large HTTP-layer frames because they're within a QUIC stream.  This was briefly mentioned in Bangkok.

There are multiple possible approaches to making this better:

  *   Move DATA off-stream.  Considered too extreme a change for this stage of the process and not helpful in all cases, but this can be implemented as an extension.  (See this unsubmitted draft<https://github.com/MikeBishop/quic-external-data>.)
  *   Frames of length 0 extend to the end of the stream.  This seemed like the architecturally cleanest way to solve it, but the prospect of arbitrary frames whose length isn't known from the beginning was potentially challenging for some implementations.
  *   DATA frames of length 0 extend to the end of the stream.  This is a more scoped change, but special-cases the DATA frame.

After discussion on the issue and on the submitted PR (#2098)<https://github.com/quicwg/base-drafts/pull/2098>, the consensus seemed roughly split between the latter two options, but most participants in the discussion seemed amenable to either.  I've merged the PR, which changed the behavior only of DATA frames.

However, Martin pointed out<https://github.com/quicwg/base-drafts/pull/2098#issuecomment-444763104> that this discussion has been entirely on GitHub, and that perhaps an opportunity for list discussion was in order.  If there's not WG consensus to proceed with this change at all, I'll revert it.  If there's consensus to use a different solution instead, I'll create a follow-up PR.

Thanks,
Mike Bishop