Stream State and PRIORITY Frames

[Scott Mitchell <[e-mail]>]

(originally posted here: https://github.com/http2/http2-spec/issues/759)

What is the expected result in terms of stream state and any potential
errors that should be generated from the following scenario:

```
1. Client [PRIORITY, id: 5] -> Server
2. Client [HEADERS, id: 3] -> Server
```

## Option 1
The server accepts both frames. Stream `3` is OPEN and stream `5` remains
in IDLE.

This behavior is verified in the h2spec verification tool via
https://github.com/summerwind/h2spec/pull/67. Also see additional
discussion there.

## Option 2
Should the use of stream ID `5` cause stream ID `3` (and all lower stream
IDs) to be implicitly closed according to the section-5.1.1 (see [1])? This
would mean after the server receives the frame from step (1) it thinks that
stream ID `3` has been closed, and when the server receives the frame from
step (2) it will respond with a connection error of type PROTOCOL_ERROR
(see [2])?

[1] https://tools.ietf.org/html/rfc7540#section-5.1.1
> The first use of a new stream identifier implicitly closes all
   streams in the "idle" state that might have been initiated by that
   peer with a lower-valued stream identifier.

[2] https://tools.ietf.org/html/rfc7540#section-5.1.1
> An endpoint that
   receives an unexpected stream identifier MUST respond with a
   connection error (Section 5.4.1) of type PROTOCOL_ERROR.