Fix/fix certificate provisioning failures caused by acme account serialization issue and localstack auth changes

[Hermann-Core]

This ticket tracks dependency and local infrastructure updates required to fix:

1. Certificate provisioning failures caused by an ACME account serialization/deserialization issue that was patched in newer versions of the instant-acme crate.
2. Local integration test failures caused by recent LocalStack Docker images now requiring an authentication token by default.

The main goal of this ticket is to stabilize certificate issuance/renewal flows and restore reliable local testing environments through dependency upgrades and explicit service version pinning.

Infrastructure / Docker updates

• Pin LocalStack Docker image version to 4.14
• Avoid floating latest tags in Docker Compose and CI environments
• Update all local development and test environments to use the pinned version consistently

Tasks

• Upgrade project dependencies
• Run certificate issuance tests
• Run certificate renewal tests
• Pin LocalStack and other services versions
• Update Docker Compose file

Acceptance Criteria

• Certificate provisioning works correctly after restart/redeployment
• ACME account persistence/loading succeeds reliably
• Certificate renewal flows continue to function correctly
• Local integration tests pass without requiring LocalStack authentication tokens
• Docker Compose environments are reproducible across machines
• No regressions in existing ACME challenge handling logic

[Awambeng]

Thanks for these improvements @Hermann-Core.

Since the ACME serialization issue was resolved mainly through the library upgrades, it might be worth adding a small 'save and load' regression test for the ACME account.

This would ensure that if a future library update breaks serialization again, we catch it during testing rather than hitting rate limits in production

[Awambeng]

I also encountered some failing tests locally. Could you please take a look as well?

[IngridPuppet]

I tried running docker compose up --build and left some comments. Please could you check?

[IngridPuppet]

I also encountered some failing tests locally. Could you please take a look as well?

Same. cargo test is treating the example code in a documentation block in bits_validation.rs as a test to run. This works though:

cargo nextest run --workspace --all-targets --all-features

Not sure if that's intended. There should be a way to document code without it being treated a test if not wanted.

[Hermann-Core]

Same. cargo test is treating the example code in a documentation block in bits_validation.rs as a test to run. This works though:

cargo nextest run --workspace --all-targets --all-features

Not sure if that's intended. There should be a way to document code without it being treated a test if not wanted.

We are running the full test suite using cargo-nextest, which by default does not execute doctest examples. I have fixed the issue though. The CI pipeline will be improved as part of the upcoming review ticket we are preparing, following the same foundation and standards already established in the cloud wallet project.

[Hermann-Core]

Hello @Awambeng @IngridPuppet thank you for the reviews. The issues have been fixed, could you have another look?

[IngridPuppet]

I can docker compose up and cargo test with the update.

[Awambeng]

Hi @Hermann-Core, thank you for adding the new test.

The current integration tests validate the full provisioning and renewal flows, but they do not explicitly verify ACME account serialization/deserialization.

Since the serialization issue was mainly resolved through dependency upgrades, I think it could still be valuable to add a dedicated regression test for the ACME account persistence flow to catch future serialization issues early. WDYT?

[Hermann-Core]

Since the serialization issue was mainly resolved through dependency upgrades, I think it could still be valuable to add a dedicated regression test for the ACME account persistence flow to catch future serialization issues early. WDYT?

Instead of creating isolated tests for each individual component of the ACME flow, I decided to validate the entire certificate provisioning flow end-to-end. This allows us to test not only the account serialization and persistence logic which are themselves part of the provisioning process, but also the interaction between all components involved in the flow. As a result, if an issue occurs at any stage of the provisioning pipeline, it can be detected through the integration test as well.

[Awambeng]

Since the serialization issue was mainly resolved through dependency upgrades, I think it could still be valuable to add a dedicated regression test for the ACME account persistence flow to catch future serialization issues early. WDYT?

Instead of creating isolated tests for each individual component of the ACME flow, I decided to validate the entire certificate provisioning flow end-to-end. This allows us to test not only the account serialization and persistence logic which are themselves part of the provisioning process, but also the interaction between all components involved in the flow. As a result, if an issue occurs at any stage of the provisioning pipeline, it can be detected through the integration test as well.

Okay, It's fine then. Thank you!

[Hermann-Core]

Hello @IngridPuppet @Awambeng I have fixed the merge conflicts, could you have another look or approve again so we can merge?