Store preferred_address.connection_id like any other new connection ID

[kazuho]

At the moment, quicly ignores preferred_address TP.

It is fine to not support preferred address, but the downside of ignoring the TP entirely is that the Connection ID being carried by the transport parameter is also ignored.

Instead, the connection ID carried by the transport parameter should be handled exactly the same as if it was received via a NEW_CONNECTION_ID frame of sequence 1. Otherwise, the number of spare connection IDs that we'd have during the lifetime of the connection decreases by one, until the server sends a Retire Prior To greater than 1.

Quoting RFC 9000:

The connection ID provided in the preferred_address transport parameter is not specific to the addresses that are provided. This connection ID is provided to ensure that the client has a connection ID available for migration, but the client MAY use this connection ID on any path. (section 9.6.3)

The Connection ID and Stateless Reset Token fields of a preferred address are identical in syntax and semantics to the corresponding fields of a NEW_CONNECTION_ID frame. (section 18.2)