Cooperative Cancellation in PasswordHash

[huven]

This PR accompanies #5123

Draft status. First test is to run CI to determine support status of std::stop_token across platforms.

Todo:

• Check std::stop_token cross-platform support
• Unittest
• Make all PasswordHash subclasses check stop_token
• Drop added supports_cooperative_cancellation() when all do
• Update documentation

Note:

• The deprecated API (non-PasswordHash based) has not been touched
• I've added the default std::nullopt only to the base class. This is not inherited by virtual overrides, which I think is ok as the default will be taken from the static class. Similar to other methods like from_params.

[coveralls]

coverage: 90.665% (-1.4%) from 92.088%
when pulling 623198a on huven:pwhash-stoppable
into a3ed3b0 on randombit:master.

[reneme]

Looking at the CI outputs, we seem to get in trouble with macOS (Xcode 13 and 14) and Android NDK. For both of which we claim to only support the "latest" version. Both could be updated on our CI: Xcode (to 26 that comes with Clang 17) and the NDK (from 28 to 29) [1, 2] which may or may not fix this issue.

Additionally the build configuration for arm32-baremetal (which links to -lnosys) fails because the symbol for __atomic_fetch_sub_4 is missing. I'm guessing that the stop token needs this for synchronization. Not sure whether that would become a showstopper, frankly.

[huven]

For macOS/iOS I know for sure it works with recent Xcode, as I already included a basic implementation in my app, works perfectly 😄.
It looks like the current images use clang 14 and 15 while stop_token was introduced at 16.

Will have some time later today to dive into this.

[huven]

Merged both PRs you linked in here, let's see what happens..

[reneme]

Merged both PRs you linked in here, let's see what happens..

Thanks. I was about to propose exactly that.

The macOS 26 PR currently doesn't work -- some Python-based test fails. But the build succeeds, despite the stop token usage. Similarly, NDK r29 seems to ship the stop token as well. So both are probably a green light (if we're willing to ditch support for older NDKs and Xcodes). 🙂

That leaves the linking issue on the "arm32-baremetal" CI job which doesn't seem to provide the required atomic functionality. 🙁

[huven]

One python test fails indeed on macos-26. I see the test is disabled on Windows.

I have one Mac here at 26, interestingly enough all tests run ok on it (though an immediate second run fails the cli_tls_socket_tests test (Error: server bind failed), but that looks like another issue).

Will debug this a bit further, would be nice if the cli_tls_proxy_tests would fail on my device too.

[huven]

Didn't succeed in reproducing the tls_proxy test failure. Installed both boost and python with the exact same version as in GitHub runner, copied the configure.py command verbatim, all tests still pass 😢

For now, I'm tempted to add macOS to the Windows exception for that test and leave fixing the test to another issue.

[...]
   INFO: Ran cli_tls_proxy_tests in 0.41 sec
[...]
Ran 238 tests with 0 failures in 7.82 seconds