I verified the PR by running the entire test suite of Odin itself with
`-sanitize:address` and also the ols test suite (which caused unique problems
before).
A test has also been added with some problematic code, Windows seems to
have problems with asan in CI or in general so it is not ran there.
The LB_ABI_COMPUTE_RETURN_TYPES block has been removed entirely because
it was unused, I got pretty confused why it didn't effect anything at
first.
Fixes#3211
A new package `core:time/datetime` has been added which can represent moments much further in the past and future than `core:time`.
It is based on *the* reference work on the subject, Calendrical Calculations Ultimate Edition, Reingold & Dershowitz.
More procedures will be added to it in the future, to for example calculate the 3rd Thursday in March to figure out holidays.
The package has been tested for more than a year and can handle dates 25 quadrillion years into the past and future with 64-bit day ordinals, or 5 million with 32-bit ones.
This also fixes a longstanding bug where converting between YYYY-MM:DD hh:mm:ss and `time.Time` and back could result in a mismatch.
RFC 3339 timestamps can now also be parsed using the `core:time` package.
This is infrequently maintained, and has been a strict subset of what is
available in `core:crypto` for a while. Instead of improving the
bindings, it is better to spend resources improving `core:crypto`.
Watching the sporadic CI failures it seems to come from these tests a
lot of the time, this PR cleans up and simplifies (while testing the
same things):
1. Lots of tests were using threads without a need for it
2. Tests had hardcoded `time.sleep` calls which is never a good idea
3. An unclear abstraction was implemented without a real need
4. They weren't being ran on non-windows
5. The `client_connects_to_open_but_not_accepting_port` was not doing
what you wanted to test for, the `tcp_server` proc was returning, and
then `dial` was called, which meant that the server already closed
and you got a refusal error. Now it correctly listens without
accepting, which even results in a different error because the kernel
buffer would have buffered the send
The max digest size for the foreseeable future will be 512 bits, and the
max block size is currently 1152 bits (SHA3-224). If people add more
exotic hash algorithms without bumping the constants when required,
tests will fail.
The stream buffer will currently be 576 bytes, which is "fine" to just
stick on the stack, and is a sensible multiple of the more common block
size of 64 bytes.
All of our crypto is modern now unless exiled to the legacy sub-package,
so move the test cases for the currently un-unified algorithms into the
main test driver file, and rename the benchmark driver to reflect
reality.
There is a lot of code duplicated in convenience methods in each hash
implementation, and having a generic hash type makes implementing
higher-level constructs such as HMAC significantly easier down the road.
