feat(rust/cbork): deterministic map decoding helper

[cong-or]

The code satisfies RFC 8949's deterministic CBOR map requirements by ensuring:

1. Key Ordering

   • Shorter keys before longer ones
   • Lexicographical ordering for equal-length keys

2. Key Uniqueness

   • No duplicate keys allowed

3. Encoding Rules

   • Uses minimal length encoding
   • No indefinite-length items

All requirements are properly validated and tested

example usage:

use minicbor::Decoder;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    // Example of a valid CBOR map with 2 entries
    let cbor_bytes = vec![
        0xA2,                   // Map with 2 pairs
        0x41, 0x01,            // Key 1: single byte string "1"
        0x41, 0x30,            // Value 1: single byte string "0"
        0x41, 0x02,            // Key 2: single byte string "2"
        0x41, 0x31,            // Value 2: single byte string "1"
    ];

    // Create a decoder with our CBOR bytes
    let mut decoder = Decoder::new(&cbor_bytes);
    
    // Decode and validate the map
    match decode_map_deterministically(&mut decoder) {
        Ok(validated_bytes) => {
            println!("Valid deterministic map! Bytes: {:?}", validated_bytes);
            // validated_bytes will contain the original CBOR bytes since they were valid
        },
        Err(e) => {
            println!("Invalid deterministic encoding: {}", e);
        }
    }

    Ok(())
}

p.s will do separate PR for abstracted cbor decoder with optional deterministic decoding w logging.

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 331/331}$ | ${\color{red}Fail: 0/331}$ |

[no30bit]

LGTM, but I've left some comments mostly on the error types.

On that topic, I am a bit hesitant about introducing DetermenisticError. Some of its variants have parallels in minicbor::decode::Error. For example, DetermenisticError::UnexpectedEof is the same as Error::end_of_input() from minicbor. It gets a bit confusing, considering the later is also wrapped under one of the variants.

If I were to implement this, I'd rather wrap the other way around: our local error within minicbor's Error::custom. Our error would then be extractable via std::error::Error::source, and we'd get the benefits of integration inside of minicbor::Decode implementations seamlessly and Error::at.

[no30bit]

Since the Decoder::skip skips over a CBOR value, which can't be represented by less than 1 byte, wouldn't it be safe to assume the ranges extracted below to be ok by definition?

Or are we testing the Decoder::skip implementation itself here?

[cong-or]

addressing this now

[cong-or]

@no30bit error handling has been addressed along with the cbor header helper which can be used for various types.