CBOR maps use Vec instead of BTreeMap

[kaczmarczyck]

We only access CBOR maps by iterating over them. They also have to be sorted, but that is asserted when reading, and as we control the inputs, we can output the elements in the correct order (we do sort before writing though, to make sure). Therefore, maps can be represented internally by Vec<Key, Value>.

This change intends to reduce the binary size and RAM usage of OpenSK.

• binary size: The functions using BTreeMap have been the largest when analyzed.
• RAM: When investigating OpenSK panic in corpus testing (tracking) #177, we noticed that BTreeMap allocates lots of memory.

This changes removes all occurances of BTreeMap. Binary size in optimized mode is reduced from 130.5 KiB to 126.9 KiB as output by:

echo 'opt-level = "z"' >> Cargo.toml
cargo bloat --release --target=thumbv7em-none-eabi --features=with_ctap1

This PR also cleans up some test code:

• cbor_array_vec is only used when actually needing to take a vec, not for `cbor_array_vec[vec![...]]
• arguments are sorted correctly (so that removing the sort_by call in cbor::writer could be removed)

All changes made are (impactful) implementation details, but we don't change any behaviour.

[ia0]

Could you provide from which number the binary size is reduced from in the description? (both for base reference and history) Ex: Binary size is reduced from XXX.X KiB to 126.9 KiB. Thanks!

[jmichelp]

Overall LGTM.
One question: CBOR being canonical, I guess that there's unicity on the keys in a map. Do we have a test for that and isn't an implementation based on Vec<> problematic here (i.e. we would need to sort then check for duplicate keys)?

[kaczmarczyck]

True! Dedup and test added.

The new binary size is 127.3 KiB, and I edited above correctly state the prior size.

[ia0]

LGTM (wasn't planning to review it, it's just that when giving an improvement it's good to have both old and new value to understand the impact)