resilient_client: Prevent authentication token leakage in logs

[ansasaki]

Add SecretToken wrapper type that automatically displays SHA-256 hash prefix (first 8 chars) instead of plaintext when logged or formatted. Actual token value accessible only via explicit reveal() call.

• Created SecretToken with cached hash for Display/Debug traits
• Updated SessionToken to use SecretToken field
• Enhanced LoggingMiddleware to redact Authorization headers

This prevents accidental token exposure through logs while maintaining debuggability by showing hash prefix for correlation.

Assisted-by: Claude Sonnet 4.5

[codecov]

Codecov Report

❌ Patch coverage is 37.25490% with 32 lines in your changes missing coverage. Please review.
✅ Project coverage is 57.19%. Comparing base (e658b57) to head (2af201e).
⚠️ Report is 3 commits behind head on master.

Files with missing lines	Patch %	Lines
keylime/src/resilient_client.rs	14.28%	24 Missing ⚠️
keylime/src/auth.rs	65.21%	8 Missing ⚠️

Additional details and impacted files

Flag	Coverage Δ
e2e-testsuite	57.19% <37.25%> (-0.07%)	⬇️
upstream-unit-tests	57.19% <37.25%> (-0.07%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
keylime/src/auth.rs	45.64% <65.21%> (+1.04%)	⬆️
keylime/src/resilient_client.rs	67.33% <14.28%> (-3.09%)	⬇️

... and 4 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ansasaki]

I'll debug what is happening with the coverage generation. Apparently, something changed in the Testing Farm side, making the script to fail downloading the coverage data. Let's see.

A simple re-run made the test to run as expected, but the coverage values are weird. It seems some coverage data is not being considered. I suspect the upstream test suite is not being included in the coverage calculation or the upstream test suite is not running completely (maybe not all features, like testing are being used),

[sergio-correia]

I'll debug what is happening with the coverage generation. Apparently, something changed in the Testing Farm side, making the script to fail downloading the coverage data. Let's see.

A simple re-run made the test to run as expected, but the coverage values are weird. It seems some coverage data is not being considered. I suspect the upstream test suite is not being included in the coverage calculation or the upstream test suite is not running completely (maybe not all features, like testing are being used),

Yeah, these coverage numbers are weird, at a first glance. It would be great if we investigated them to find out whether they are correct. In any case, the change looks good to me, thanks!

[ansasaki]

I'll debug what is happening with the coverage generation. Apparently, something changed in the Testing Farm side, making the script to fail downloading the coverage data. Let's see.
A simple re-run made the test to run as expected, but the coverage values are weird. It seems some coverage data is not being considered. I suspect the upstream test suite is not being included in the coverage calculation or the upstream test suite is not running completely (maybe not all features, like testing are being used),

Yeah, these coverage numbers are weird, at a first glance. It would be great if we investigated them to find out whether they are correct. In any case, the change looks good to me, thanks!

Checking the logs of the upstream/run_rust_keylime_tests, I didn't see the new added tests being executed. I suspect that we are running the tests from a different branch (probably master) by using the code in rust-keylime_tests without checking if it is in the correct branch. I will continue my investigation, but will fix in another PR.