fix no-std support

[japaric]

this PR

• makes the alloc feature not pull in the optional ring dependency
• fixes cargo build --no-default-features --features alloc
• adds a CI check to prevent no-std support breaking in the future

fixes #143
fixes #144

[codecov]

Codecov Report

Merging #145 (4948ea8) into main (aa818ab) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #145   +/-   ##
=======================================
  Coverage   96.01%   96.01%           
=======================================
  Files          15       15           
  Lines        4065     4065           
=======================================
  Hits         3903     3903           
  Misses        162      162           

Files Changed	Coverage Δ
src/signed_data.rs	99.18% <ø> (ø)
src/crl.rs	99.65% <100.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[cpu]

Thanks!

I think the different performance characteristics of the BTreeMap vs HashMap are probably not significant enough in this use-case to merit trying to do more complicated abstraction to allow switching between the two based on features.

Running cargo bench on tip of main and on this branch shows that the BTreeMap-based owned representation is faster for the initial parsing of a chonky CRL and only a bit slower for lookups. I think it's a reasonable trade-off.

HashMap:

test bench_parse_owned_crl_large      ... bench: 517,452,454 ns/iter (+/- 98,860,890)
test bench_parse_owned_crl_medium     ... bench: 176,374,780 ns/iter (+/- 32,024,576)
test bench_parse_owned_crl_small      ... bench:     186,129 ns/iter (+/- 7,450)
test bench_search_owned_crl_large     ... bench:           9 ns/iter (+/- 3)
test bench_search_owned_crl_medium    ... bench:           9 ns/iter (+/- 3)
test bench_search_owned_crl_small     ... bench:          10 ns/iter (+/- 1)

BTreeMap:

test bench_parse_owned_crl_large      ... bench: 296,112,924 ns/iter (+/- 37,342,479)
test bench_parse_owned_crl_medium     ... bench:  89,594,215 ns/iter (+/- 13,807,766)
test bench_parse_owned_crl_small      ... bench:     175,042 ns/iter (+/- 19,676)
test bench_search_owned_crl_large     ... bench:          63 ns/iter (+/- 16)
test bench_search_owned_crl_medium    ... bench:          69 ns/iter (+/- 13)
test bench_search_owned_crl_small     ... bench:          50 ns/iter (+/- 2)

[djc]

To be fair, lookups are like 7x slower with a BTreeMap, but that penalty probably gets lost in the noise of actual crypto operations.

[cpu]

@ctz Thoughts? Ready for merge queue?

[cpu]

I'm going to bypass the merge queue for this one while the dependency fetching flake is happening. It keeps getting bounced from the queue 🎰