Fix issues verifying proofs built from 9.9.9.9

Sometimes proofs built from 9.9.9.9 include duplicate NSEC3
records, which we have to filter out before signature verification
or we'll get spurious signature verification errors.

Manually implement Debug for `NSecTypeMask` so its readable

Update trust anchors to add the new 2024 key

Bump version to 0.6.5 for new less-code-size feature

Use Karatsuba mul less when built with `slower_smaller_binary`

This is a less than 5% reduction in performance and reduces code
size for the crypto module from 26.7KiB to 26.5KiB.

Drop 384-bit multiplication impl with `slower_smaller_binary`

...instead using the 512-bit multiplication impl and dropping the
resulting high bytes. This is much slower, but very few zones
actually use secp384r1 so in practice this shouldn't really matter.

This is a less than 5% reduction in performance and reduces code
size for the crypto module from 27.4KiB to 26.7KiB.

Skip squaring implementations when `slower_smaller_binary` is set

...instead just using the normal multiplication code.

This is less than a 5% reduction in performance and reduces code
size for the crypto module from 30.8KiB to 27.4KiB.

Add a feature to slow things down for a smaller binary

Very marginally reduce branching in Karatsuba multiplication

Bump version to 0.6.4 for fixed MSRV, errors, and perf improvements

Technically this violates SemVer, but the only SemVer-breaking
change was changing some return types from `Result<T, ()>` to
`Result<T, ErrEnum>`. While someone could have been unwrap'ing the
error and storing the `()`, its sufficiently unlikely that it seems
fine to just bump the patch version to ship all the improvements
without a minor version bump.

Optimize U256/384 `times_three` methods substantially

...for a total ~7% performance gain in EC verification

Use gradeschool multiplication for `mul_3/4` rather than Karatsuba

This is about a 15% performance improvement for all signature
verification, plus about 500B less total code

Use a single const-generic `sub` method rather than macro-izing

Use a single const generic `add` method rather than macro-izing

Make multiplication take array references rather than slices

This seems to reduce binary size marginally by avoiding slice
bounds checking.

Make subtraction take array references rather than slices

This seems to reduce binary size marginally by avoiding slice
bounds checking.

Make addition take array references rather than slices

This seems to reduce binary size marginally by avoiding slice
bounds checking.

Move mont reduction impls out of generic'd struct impl

This reduces binary size by ~600B due to the monomorphizer failing.

Add a dummy binary to test code size with `cargo bloat`

Print info about which test failed when a test panics

Merge remote-tracking branch 'github/pull/2'

Correct the MSRV tag as we use several 1.61-stable const features

Add a `RUST_VERSION` env argument to `test.sh` to enable MSRV tests

Fix outdated docs

Provide readable errors when we fail to build proofs

This should make proof building much easier to deal with for
humans.

Add a simple README

Bump patch version for new `Hash` impls

Implement `Hash` for all Resource Records and `Name`

Bump patch version for new MSRV

Drop MSRV to 1.63 w/o `RUSTC_BOOTSTRAP` hacks with a bad assumption

While the Rust language reference says "you should not rely on
this", in practice slices are laid out in memory as a two-tuple of
`(pointer, length)`. Here we rely on that assumption to replace
`alloc::slice::from_raw_parts` with a `core::mem::transmute`.

Bump patch version for `TxtBytes` iteration behavior

Correct `TxtBytes` iteration behavior, fixing `Txt::json()`

Bump minor version for corrected strange `Txt` signature validation

Add a new query test hosted on an OVH DNS server

Keep encoding information in `Txt` `RR`s

Sadly `TXT` records can be encoded in many ways (as they're
chunked, and chunks can be any size), and are signed in the way in
which we receive them on the wire. Thus, we must keep the encoding
information we receive on the wire around in `Txt`s to ensure we
can validate their signatures.

Here we do so, creating a pile of new machinery to store `Txt` data
as a series of up-to-255-byte chunks.

Bump patch version for length check and extra `RRSig` ignoring

Correct length check in `read_nsec_typtes_bitmap`

This fixes a reachable panic when deserializing certain `RR`s,
found by the fuzzer.

Rm debug assertions that `read_wire_packet_name` empties its buffer

These assertions are spurious and reachable when fuzzing, and thus
are simply removed.

Fix fuzz test build

Call `RR.json()` when deserializing RRs in fuzzing

To improve coverage

Ignore spurious `RRSig`s which sign `DNSKEY`s with a ZSK

There's no reason to include an `RRSig` signing `DNSKEY`s with a
ZSK - validators only care about the KSK signing `DNSKEY`s, hence
*Key*-Signing Key. However, OVH appears to include such signatures
anyway, which we must ignore.

Here we do so by pre-filtering the `RRSig`s we try to validate by
key tag before calling `verify_rrsig`. This causes us to calculate
the key tag a few extra times, but that's not a huge deal.

Avoid overriding $RUSTFLAGS when needed for rustc 1.63

Bump minor version for crypto speedup and validation step limit

Limit the number of validation steps we'll take

While proofs should be rather computation-time-limited through
limits on their size, its still nice to limit proof validation time
more directly through the same constant we already do to limit
proof construction complexity.

Provide sources for the EC math and use a faster double algorithm

Add some comments about mont reduction to make it a bit clearer

Check the assumption that P-N is tiny

Write out "Point at Infinity"

Rename `IntModP`/`IntModN` to `CurveField`/`ScalarField`

which improves readability greatly

Add a dummy `http.rs` main to make default rust builds work

Address further clippy lints

Make crypto/ clippy-clean, mostly by telling clippy to shut up

Better support rustc 1.64+ by not requiring `RUSTC_BOOTSTRAP`

Address new rustc warnings around unused variables

Fix const build error in the previous commits

Clean up and better comment math somewhat further

Clean up carry/debug assertions in multiplies/squaring

Clean up + test add/sub/negate, fixing a debug assert in negate

Swap `add_one!(_)` for `add_u64!(_, 1)`

Set default-features = false on uniffi, not that it does much

Add the standard uniffi-bindgen bin target

Expose uniffi bindings for building and verifying proofs

Bump crate version for new `Clone` impl

Derive `Clone` for `ProofBuilder`

Filter using `VerifiedRRStream::resolve_name` in wasm

When resolving a name in WASM we should let `resolve_name` handle
C/DNAMEs, which we do here.

Bump version to 0.5.2 for dropping ring dep

Iteratively hash rather than building a vec then hashing

... in signature checking.

Now that we control the signature checking API, we don't have to
pass a full buffer and can build our own hashes, avoiding the
allocation.

Make `write_u16_len_prefixed_data` generic over the type of output

In the next commit this will be used to write RRs directly into
hashers when validating signatures, rather than serializing them
into `Vec`s then hashing.

Add the wycheproof test cases for our crypto implementation

Swap `ring` for our own in-crate ECDSA validator

While `ring` is great, it struggles with platform support and has a
fairly involved dependency tree due to its reliance on C backends.

Further, while the `RustCrypto` org tries to stick to Rust, in
doing so it takes on more (unnecessary) dependencies and has a
particularly unusable MSRV policy. Finally, its contributor base
has historically not been particularly friendly.

Thus, sadly, there's not really a good option for doing ECDSA (non-
secp256k1) validation using a third-party crate.

Instead, we go our own way here, adding an in-crate ECDSA
validator over secp{256,384}r1.

This also adds a new bench, showing our secp256r1 validation is,
sadly, something like 50x slower than OpenSSL.

Add U256/U384 and mod-const-prime wrapper utilities of both.

In the next commit we'll add support for secp256r1 and secp384r1
validation, which require 256-bit and 384-bit integers. To make
their implementation simple, we also add wrapper structs around
the new integers which are modulo a const-prime, storing and
handling the values in montgommery representation.

Add a simple benchmark of 2048-bit RSA validation

This shows our RSA is only roughly 3.5x slower than OpenSSL.

Swap `ring` for our own in-crate RSA validator

While `ring` is great, it struggles with platform support and has a
fairly involved dependency tree due to its reliance on C backends.

Further, while the `RustCrypto` org tries to stick to Rust, in
doing so it takes on more (unnecessary) dependencies and has a
particularly unusable MSRV policy. Finally, its contributor base
has historically not been particularly friendly.

Thus, sadly, there's not really a good option for doing RSA
validation using a third-party crate.

Instead, we go our own way here, adding an in-crate RSA validator.

Add a relatively simple mostly-const-fn bigint math implementation

While `ring` is great, it struggles with platform support and has a
fairly involved dependency tree due to its reliance on C backends.

Further, while the `RustCrypto` org tries to stick to Rust, in
doing so it takes on more (unnecessary) dependencies and has a
particularly unusable MSRV policy. Finally, its contributor base
has historically not been particularly friendly.

Thus, sadly, there's not really a good option for doing RSA
validation using a third-party crate.

Instead, in the next commit we'll go our own way and add an
in-crate RSA validator. This takes the first step, adding a bigint
implementation that works up to 4096 bits (the longest allowed RSA
keys in the DNS).

Sadly, once we get to EC math we'll really want most of our math
operations to be const fns, which provides some additional limits.
Absent a better way to do subslicing on rustc 1.63, this commit
introduces a dependency on the `const_slice_from_raw_parts`
feature, which appears to work fine on 1.63 with
`RUSTC_BOOTSTRAP=1` set, and was stabilized in 1.64.

Enable (minimal) optimization in tests

As of the next commit, our tests now have to do in-crate crypto, so
even minimal optimization provide a huge speedup.

Test fuzzers build and release build in test.sh

Add support back for SHA-384 DS records

While these are relatively unused, support for SHA-384 was recently
added in `bitcoin_hashes`, which we use here for DS validation.

Move RRSig loop to after DS loop to be more mindful of KeyTrap

In general we were mostly fine regarding KeyTrap, as we largely
fail after any invalid signature and only loop if a signature or
key required an unknown algorithm. Thus, addressing KeyTrap is
mostly an exercise in adding comments.

However, we did verify all DS hashes every time we went to verify
a single DNSKey RRSig, which is potentially some work, which we
fix here, leading to a nice simplification in `verify_rr_stream`.

Bump version for NSEC/3 validation

Add new tests to test NSEC validation behavior

Drop NSEC/3 records from `VerifiedRRStream::verified_rrs`

`verified_rrs` is intended to include only the records a user may
want, not signatures and proof records. Thus, like we remove
RRSIG/DS records, here we also remove NSEC/3 records.

Validate NSec/3 records prove non-existence when handling C/DNAMEs

When handling C/DNAME RRs we're required to validate that NSEC/3
records exist proving non-existence of the sought record itself. We
do this here.

Refresh existing test data and add NSEC/3 records

This refreshes all our existing test vectors to use new timestamps,
as well as including the newly-required NSEC/3 records.

Add base32 parser which is needed for NSEC3 validation

Correct `NSecTypeMask::contains_type` and add `from_types` builder

The low-bit-masking in `NSecTypeMask::contains_type` was incorrect,
leading to spuriously looking at the wrong bit position within the
correct byte.

While we're at it, we also add a new constructor which allows for
bits to be set.

Use `bitcoin_hashes` rather than `ring` for hashing

While `ring` is great, it struggles with platform support and has a
fairly involved dependency tree due to its reliance on C backends.

Further, while the `RustCrypto` org tries to stick to Rust, in
doing so it takes on more (unnecessary) dependencies and has a
particularly unusable MSRV policy. Finally, its contributor base
has historically not been particularly friendly.

Thus, for the best platform support, we'd like to avoid both. Here
we take the first of several steps towards that goal, using
`bitcoin_hashes` for our SHA-1/SHA-2 operations instead.

Bump version for NSEC/3 record type additions and proof inclusion

Include any relevant NSec/NSec3 records in generated proofs

Add de/serialization and structs for NSec and NSec3 records

Define a util method to convert a type value to the type's name

Add debug checks that we don't leave data behind after an RR

Refuse to include \s in the JSON output of a TXT record

Force all names to lowercase ASCII as it is the canonical form

Add trivial helper method to get the label count in a `Name`

Bump version number for DNAME support

Swap test domain to something more sustainable

Add support for DNAME resolution

Add note about DoH proof building usage.

Bump version for bug fixes and new query APIs

Add WASM/JS support for doing full lookups using DoH