#2057: Shuffle outgoing transport parameters.

[mstyura]

I propose to remember the order in which write of the params should be performed when TransportParameters are crated. Then this order is used to write to wire format.
PR currently split into two commits:

1. Do the permutation using hard-coded IDs of prams;
2. Some refactoring to store the IDs into enum.

[djc]

I propose to remember the order in which write of the params should be performed when TransportParameters are crated. Then this order is used to write to wire format.

Why do you want to store the order? That seems largely unrelated to the stated goal of this PR to shuffle transport params.

I think the commit introducing an enum should come first. Suggest extracting the macro from its current location in a separate commit so that it can get only the necessary modifications in place in the further commits.

[mstyura]

Why do you want to store the order? That seems largely unrelated to the stated goal of this PR to shuffle transport params.

@djc maybe I'm missing something, but inside TransportParameters::write I don't have access to random generator passed form Connection to perform shuffle at that time and in my previous MR it was suggested to not to use rand::thread_rng() directly. So the solution was to store the write order inside constructor where I have an access to random generator injected from Connection and use this order during write. Let me know if you think this could be done differently.

I think the commit introducing an enum should come first. Suggest extracting the macro from its current location in a separate commit so that it can get only the necessary modifications in place in the further commits.

Do you mean only re-order commits in this MR or I should better to put refactoring related to TransportParameterId into separate PR and wait until it merged and update this MR with only shuffling implemented?

[djc]

Why do you want to store the order? That seems largely unrelated to the stated goal of this PR to shuffle transport params.

@djc maybe I'm missing something, but inside TransportParameters::write I don't have access to random generator passed form Connection to perform shuffle at that time and in my previous MR it was suggested to not to use rand::thread_rng() directly. So the solution was to store the write order inside constructor where I have an access to random generator injected from Connection and use this order during write. Let me know if you think this could be done differently.

Ah, makes sense -- sorry for the noise!

I think the commit introducing an enum should come first. Suggest extracting the macro from its current location in a separate commit so that it can get only the necessary modifications in place in the further commits.

Do you mean only re-order commits in this MR or I should better to put refactoring related to TransportParameterId into separate PR and wait until it merged and update this MR with only shuffling implemented?

Reordering commits in this PR should be okay.

[mstyura]

Reordering commits in this PR should be okay.

Re-ordered commits and hopefully a bit enhanced implementation by allowing == between TransportParameterId and u64 to avoid several usages as u64 casts inside guard of match expression.

Ah, makes sense -- sorry for the noise!

Also a bit changed implementation of reordering. Instead of storing all transport parameter IDs inside write_order array inside TransportPrameters which occupied 21 * u64 = 168 bytes spaces in struct I stored 21 * u8 values which treated as indices of SUPPORTED_TRANSPORT_PARAMETERS array.

[djc]

This is looking pretty good!

[Ralith]

Thanks!

[mstyura]

@djc, @Ralith thank you very much for review, feedback and patience! And accepting this change!

[Ralith]

Thanks for your contribution! I've been specifically wanting this for a while.