fix 32 bit support, add i686-unknown-linux-gnu CI target

[cpu]

ci: add a 32bit target build w/ cross.

This commit introduces a CI target that uses cross to cross-compile for a i686-unknown-linux-gnu target to ensure we maintain 32bit arch compatibility. Unfortunately I don't believe GitHub actions has a native 32bit runner so cross-compilation is our best bet.

Before applying the subsequent fix commit this task fails with the error reported in #112:

   Compiling rustls-webpki v0.101.0 (/home/runner/work/webpki/webpki)
error[E0080]: evaluation of constant value failed
   --> src/der.rs:246:45
    |
246 | const LONG_FORM_LEN_FOUR_BYTES_MAX: usize = (1 << (8 * 4)) - 1;
    |                                             ^^^^^^^^^^^^^^ attempt to shift left by `32_i32`, which would overflow

der: fix DER max size constants for 32bit targets.

This commit introduces a fix to the LONG_FORM_LEN_XXX_BYTES_MAX constants in the der module to avoid overflow on 32bit targets.

Resolves #112

cargo: bump version to 0.101.1

Prepare for a release that includes the 32bit arch fix.

[codecov]

Codecov Report

Merging #113 (d4aa00a) into main (d9b4338) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #113   +/-   ##
=======================================
  Coverage   95.36%   95.36%           
=======================================
  Files          15       15           
  Lines        3346     3346           
=======================================
  Hits         3191     3191           
  Misses        155      155           

Impacted Files	Coverage Δ
src/der.rs	98.42% <ø> (ø)

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

[complexspaces]

Question: This seems to add about a minute to the CI runtime. Do you think its worth caching the install or using cargo-binstall for a pre-compiled version?

[cpu]

I was hesitant to add any 3rd party actions since I think the project has taken a pretty conservative stance on those in the past.

I'm not familiar with cargo-binstall but it does sound interesting. Maybe we could consider the speed optimizations in a follow-up once the breakage is addressed?

[cpu]

Looks like https://github.com/marketplace/actions/install-development-tools would maybe be the best way to integrate (?)

[cpu]

The "is this secure" part of the FAQ (https://github.com/cargo-bins/cargo-binstall#faq) gives me some pause :-/

[complexspaces]

Their description doesn't seem horribly problematic (they go from crates.io -> GitHub), but its probably not worth the 1 minute of CI time then if we're both slightly hesitant. I was hoping there was a more clear answer for pre-compiled binaries.

[cpu]

Tacked on a version bump commit with the assumption we'll want to turn around a v0.102.0 v0.101.1 release when this lands.

[cpu]

I will do a second release prep checkist PR afterwards with a README changelog update.

[djc]

I think this can be 0.101.1 instead of 0.102.0? No semver compatibility was hurt in this PR.

[cpu]

I think this can be 0.101.1 instead of 0.102.0? No semver compatibility was hurt in this PR.

Oops, you're right. Fixing.

[cpu]

Merging this since I'd like to get the issue solved ASAP. If @ctz has further refinements in mind I will chase them separately.

[cpu]

I will do a second release prep checkist PR afterwards with a README changelog update.

#114