Change illegal PRIORITY frame to a conn error

[martinduke]

Fixes #2507.

[kazuho]

Has this been the only case where a protocol violation resulted in a stream error? Or should we check if there are similar cases and file PRs as necessary?

I ask this, because IIUC at least some of us considered the proposal as a change of design principle, to stop localizing such errors, and I wonder if the change made in this PR is a tip of an iceberg.

[martinduke]

I haven't comprehensively reviewed the draft, but having just implemented the HTTP/3 frame parser, I can say that other UNEXPECTED_FRAME instances are connection errors.

Furthermore, PRIORITY frames can arrive on the control stream. If there were a stream error there it would have to take down the connection anyway.

[MikeBishop]

@kazuho, that's a good question. Previously, the philosophy has been that connection errors are ones which screw up the state so badly you can't trust the connection to proceed correctly. It's a reasonable, but not bulletproof, argument that a peer which doesn't obey the protocol has the same implication -- you can't trust the connection.

If you see other protocol violations which are stream-local errors, please file issues and we'll discuss.