fix: Accept or reject incoming frames based on self.local_max_path_id instead of Connection::max_path_id

[matheus23]

This adds a previously failing test case that best illustrates the problem.

Here's a picture anyways:

When the server receives a MAX_PATH_ID frame and agrees to increase it, it'll increase it after sending a MAX_PATH_ID frame itself.
Now, from the server's perspective the maximum path ID might be set to 14 (a value I saw in practice).
Then it starts issuing NEW_CONNECTION_ID frames with path IDs up to what it thinks is the max path id.
However, these two datagrams might get reordered. This is what we synthetically make happen in the test issue_max_path_id_reordered.
Then, the client will receive newer NEW_CONNECTION_ID frames while it still thinks the max path ID might be something like 12 and promptly close the connection with a protocol violation.

The fix I propose is to be more lenient when reading incoming packets. The NEW_CONNECTION_ID frame we got IMO is fine because we've already sent out a MAX_PATH_ID frame with 14. The fact that the other side hasn't sent us a MAX_PATH_ID frame is kind of secondary.
The other possible fix would be to delay the remote using any higher path IDs until it made sure the MAX_PATH_ID frame was acknowledged. I think this adds unnecessary delays.

The specification doesn't really seem to agree with me on this.
Section 4 says:

Receipt of multipath-specific frames that use a path ID that is
greater than the announced Maximum Paths value in the MAX_PATH_ID
frame or in the initial_max_path_id transport parameter, if no
MAX_PATH_ID frame was received yet, MUST be treated as a connection
error of type PROTOCOL_VIOLATION.

I interpret the MAX_PATH_ID frames as the ones that are received, due to it referring to having received them or not in the next sentence.
This means the situation from the picture above would be the connection's flow according to the specification. (But I think that's a specification bug.)

[flub]

Nice, but please update the description because as discussed this is not being more lenient. This is rather the correct interpretation of the spec.

[matheus23]

I'm just going to merge the two commits separately, if that's fine by you. The description isn't included in that case.