Unused parameter in WithTryPrivate causing client to send incorrect version byte in header.

[victornor]

Closes #2122
As described in the issue, the MQTTNet.Client sends incorrect version in the connect header, causing the server to respond with an unsupported protocol exception.

Digging into the encoding code, it turns out the issue is rooted in the EncodeConnectPacket method in MqttV3PacketFormatter.

If TryPrivate is true (default), a bitwise OR operation is applied to the protocol version (I don't know why this is done).

var protocolVersion = 3;
if (packet.TryPrivate)
{
    protocolVersion |= 0x80;
}

bufferWriter.WriteByte((byte)protocolVersion);

This results in the connect header containing an incorrect version:
(hex): 10 df 04 00 06 4d 51 49 73 64 70 (83) 82 00 0f 00
Instead of the expected
(hex): 10 df 04 00 06 4d 51 49 73 64 70 (03) 82 00 0f 00

After fixing the unused parameter in WithTryPrivate and using .WithTryPrivate(false), the connection is successful and no longer throws an UnsupportedProtocolVersion exception.

[chkr1011]

@victornor to my Suprise this feature seems to be broken since a while and only worked when using protocol version 3.1 (and not with 3.1.1). I added a bit of code to match the implementation in mosquitto.

Please let me know what you think.

[victornor]

Looks good to me. TryPrivate didn't seem implemented to me, so defaulting to true had me a bit confused.

[victornor]

@dotnet-policy-service agree