This is a bit "belt and suspenders" in that the build scripts are also
the code setting the `log` crate feature that strips the logs, but it
does at least add confidence that we haven't flipped a condition
somewhere, or that the `log` crate feature doesn't work the same way
anymore.
This means they'll be shipped to clients, but still filtered out of
the device builds on Android (via having two separate libraries on
disk) and iOS (by not being included in non-simulator builds). The
biggest benefit of this is dropping the :android:makeTestJniLibraries
step for running libsignal's Android tests.
The main benefit of this is not our *own* type-checking; it's that
mypy will error out if you try to use a too-new Python API. And in
fact, we were already relying on Python 3.9 and didn't realize.
check_code_size.py works with JSON, so it still uses Any a fair bit.
Run tests that call native TESTING_ functions on Android. This requires
building a separate version of libsignal_jni.so with the testing functions
included. The test code is still omitted from the published artifacts.
Follow-up to ec4faf26 where we tried to guess if the build directory
path was short enough for non-long-path-aware build tools. Give up on
that and just always use $RUNNER_TEMP if that's shorter.
Otherwise, we can run into paths that exceed the classic Windows path
limit due to the nesting of build systems (GitHub Actions > node-gyp >
Cargo > CMake > Visual Studio). Unfortunately, at least some of Visual
Studio's tools are not long-path-aware.
On Windows, node-gyp tries to be helpful by changing forward slashes
to backslashes and making paths relative to the source root rather
than the build directory, and indeed we rely on that. However, it has
to guess what's a path and what isn't. Previously, we worked around
that by manually stripping the prepended "..\", but the node-gyp
maintainers suggested a better workaround of using joined arguments
instead (`--foo=bar` instead of `--foo bar`).
