Fix a couple of packet processing bugs

[ivmarkov]

As mentioned in #177, this is the follow-up PR that addresses the actual two bugs I found:

(1) In mrp.rs (our message ACK and re-transmission logic):

• The case where we might get an ACK ID which is different (= earlier) than the one we expect was logged as an error! but not handled in any way. As a result, the logic was assuming that we got ACK for the ID we were waiting for and stopped re-transmitting the message, which is wrong!
• How it should be handled:
  • Receiving an ACK for an earlier message than the latest we've sent is completely normal. This often happens when we re-transmit a message more than once: once we receive an ACK for the first transmission of the message we of course stop re-transmitting and proceed the conversation - however - it is completely possible that we receive a late "ACK" for an earlier retransmission we did send. No, this won't necessarily be detected by the msg duplication logic in the session, if this is the latest message sent by the other peer.
  • The fix is to simply error out with ErrorCode::Duplicate because this message - in fact - is a duplicate. And then send an ACK if the message requires it.

(2) in core.rs, function decode_packet:

• Turns out we were happily creating NEW exchanges for late-arriving ACKs! This was happening because once we receive an ACK for the last message of an exchange, we of course remove the exchange. However, if we have sent the last message more than once, we might receive multiple ACKs for it, but all later ones should just be discarded, rather than initiating a new exchange
• The fix was to simply never to open a new exchange for ACK messages. I did it for ACKs and SC status reports, as both cannot initiate an exchange, though the real offender was ACKs
• Note that the function is reorganized a bit even if the fix was simple: this is to improve a bit the readability

Finally, the following additional logging adjustments:

• Receiving an ACK for an exchange which is not there (anymore) is now a warning, as it is definitely not an error on noisy channels
• Ditto for the mrp "mismatch" logic
• Ditto for receiving an encrypted message for a missing session. This happens during pase/case negotiation once the original unencrypted session is removed and a new encrypted one is created. Just like with the "missing exchange" case, we might receive extra ACKs for a session which is no longer there if the channel is noisy
• Encrypted messages which did not have a session were previously wrongly displayed as a MsgSyncCounter request, due to the proto header not being decoded (as we don't have a session, and thus proto hdr default state was containing 0s for opcode and proto ID). This is now fixed.

[ivmarkov]

Just found the dump showing the "mrp" issue (the first one) and why the fix is what it is. JFYI:

>>>>> UDP [fe80::8d7:cf23:8b0b:f715%2]:51398 [S,SID:0,CTR:a8ed77a,SRC:6584ffecdb8c6893][I|R,EID:6247,PROTO:0,OP:20]
SC::PBKDFParamRequest
 => Processing (new exchange)
I (13346) rs_matter::transport::core: Exchange 0::0 [SID:0,RSID:0,EID:6247]: Accepted
I (13346) rs_matter::respond: Responder: Handler 0 / exchange 0::0: Starting
I (13356) rs_matter::transport::exchange: 
<<<<< UDP [fe80::8d7:cf23:8b0b:f715%2]:51398 [U,SID:0,CTR:75d6397,DST:6584ffecdb8c6893][A|R,EID:6247,PROTO:0,OP:21,ACTR:a8ed77a]
SC::PBKDFParamResponse
 => Sending
I (13576) rs_matter::transport::exchange: 
<<<<< UDP [fe80::8d7:cf23:8b0b:f715%2]:51398 [U,SID:0,CTR:75d6397,DST:6584ffecdb8c6893][A|R,EID:6247,PROTO:0,OP:21,ACTR:a8ed77a]
SC::PBKDFParamResponse
 => Re-sending
I (13606) rs_matter::transport::core: 
>>>>> UDP [fe80::8d7:cf23:8b0b:f715%2]:51398 [S,SID:0,CTR:a8ed77a,SRC:6584ffecdb8c6893][I|R,EID:6247,PROTO:0,OP:20]
SC::PBKDFParamRequest
 => Duplicate, sending ACK
I (13616) rs_matter::transport::core: 
<<<<< UDP [fe80::8d7:cf23:8b0b:f715%2]:51398 [U,SID:0,CTR:75d6398,DST:6584ffecdb8c6893][A,EID:6247,PROTO:0,OP:10,ACTR:a8ed77a]
SC::MRPStandAloneAck
 => Sending (system)
I (13636) light_eth: Light toggled
I (13716) rs_matter::transport::core: 
>>>>> UDP [fe80::8d7:cf23:8b0b:f715%2]:51398 [S,SID:0,CTR:a8ed77b,SRC:6584ffecdb8c6893][I|A|R,EID:6247,PROTO:0,OP:22,ACTR:75d6397]
SC::PASEPake1
 => Processing
I (16596) rs_matter::transport::exchange: 
<<<<< UDP [fe80::8d7:cf23:8b0b:f715%2]:51398 [U,SID:0,CTR:75d6399,DST:6584ffecdb8c6893][A|R,EID:6247,PROTO:0,OP:23,ACTR:a8ed77b]
SC::PASEPake2
 => Sending
>>>> HERE >>>>: W (16616) rs_matter::transport::mrp: Mismatch in retrans-table's msg counter and received msg counter: received 75d6397, expected 75d6399.
I (16616) rs_matter::transport::core: 
>>>>> UDP [fe80::8d7:cf23:8b0b:f715%2]:51398 [S,SID:0,CTR:a8ed77c,SRC:6584ffecdb8c6893][I|A,EID:6247,PROTO:0,OP:10,ACTR:75d6397]
SC::MRPStandAloneAck
 => Duplicate, sending ACK

The last ^^^ message is what causes the MRP "issue", and the reason is, the peer receives our second PBKDFParamResponse very late. By that time, the conversation has advanced to PASEPake1 of which we are awaiting an ACK.