This commit replaces all TLS connection code with wolfssl.
The certificate parsing code has to remain for now, as wolfssl does not
seem to have any exposed API for that.
The C++ standard does not allow specifying the template parameters in
constructor declarations, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202#c8.
Converting constructors have a higher priority that user-defined
conversion functions; let's constrain `Gfx::Size<T>(Gfx::Size<U>)` to
only be considered when `U` is convertible to `T`. This lets us fall
back to conversion operators in the case of `UISize` -> `IntSize`, for
instance. Clang is still okay without this, but MSVC would error out
similarly: https://godbolt.org/z/PTbeYPM7s
Note that a not-yet-committed patch is required for full compilation:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784#c3
These changes are compatible with clang-format 16 and will be mandatory
when we eventually bump clang-format version. So, since there are no
real downsides, let's commit them now.
This is in line with what the spec states, the previous implementation
excluded the case where the original message's length is a multiple of
block_size, which would lead to a full block of padding.
We are currently using Core::DateTime, which is meant to represent local
time. However, we are doing no conversion between the parsed time in UTC
and local time, so we end up comparing time stamps from different time
zones.
Instead, store the parsed times as UnixDateTime, which is UTC. Then we
can always compare the parsed times against the current UTC time.
This also lets us store parsed milliseconds.
Previously, when calling `BigFraction::from_string()`, the fractional
part of the number was always treated as positive. This led to an
incorrect result if the input string was negative.
Previously, constructing a `UnsignedBigInteger::from_base()` could
produce an incorrect result if the input string contained a valid
Base36 digit that was out of range of the given base. The same method
would also crash if the input string contained an invalid Base36 digit.
An error is now returned in both these cases.
Constructing a BigFraction from string is now also fallible, so that we
can handle the case where we are given an input string with invalid
digits.
A bunch of users used consume_specific with a constant ByteString
literal, which can be replaced by an allocation-free StringView literal.
The generic consume_while overload gains a requires clause so that
consume_specific("abc") causes a more understandable and actionable
error.
