Refactor/make certificate provisioning configurable

[Hermann-Core]

Make certificate provisioning configurable to support multiple provisioning strategies and refactor the certificate manager to use the builder pattern for construction, removing the inline startup construction.

Acceptance Criteria

• Operators can choose between ACME and store-based provisioning.
• Store-based provisioning loads certs from filesystem or supported secrets store.
• Hot-reload works for store strategy and invalidates the certificate chain cache.
• Certificate manager is constructed via a builder pattern.
• Missing required components produce clear validation errors at build time.
• All existing tests pass and new tests cover builder and store provisioning paths.

[martcpp]

@Hermann-Core pls resolve this conflict

[Ngha-Boris]

Hello @Hermann-Core Please take a look at these comments

[Ngha-Boris]

Issue: Cache re-population missing after store provisioning

After persisting the certificate data and signing key (lines 217-218), the certificate chain cache is not being updated. The code only persists to storage but doesn't update the in-memory cache that other parts of the system rely on.

Suggestion: Add cache update call after line 218:

manager.cache_provisioned_chain(&certificate_data.certificate).await?;

This ensures the cache is invalidated and re-populated with the new certificate data.

[Ngha-Boris]

Issue: Missing HashiCorp Vault Support

The ticket deliverables mention implementing Store backend loading from "HashiCorp Vault", but this variant is missing from the StoreProvisioningSource enum. Only Filesystem, Storage, and SecretsStorage are implemented.

Suggestion: Add a HashiCorpVault variant or create a follow-up issue to track this missing deliverable from the ticket requirements.

[Ngha-Boris]

Issue: Unused Import

The Account import from instant_acme is not used in this file.

Suggestion: Remove the unused import:

use instant_acme::HttpClient;

[Ngha-Boris]

Issue: String-based Strategy Name Comparison

Using string comparison (strategy.name() == "acme") for determining strategy type is fragile. If someone changes the name returned by AcmeProvisioningStrategy, this validation will break.

Suggestion: Consider using a type-based approach or const for the strategy name:

const ACME_STRATEGY_NAME: &str = "acme";
let strategy_uses_acme = strategy.name() == ACME_STRATEGY_NAME;

Or better yet, add a method to the trait:

fn is_acme(&self) -> bool { false }  // default impl

[Ngha-Boris]

Issue: No Validation for provisioning_strategy

The provisioning_strategy field uses String type without validation. This allows invalid values to be passed in.

Suggestion: Consider using an enum for compile-time safety:

pub enum ProvisioningStrategy {
    #[serde(rename = "acme")]
    Acme,
    #[serde(rename = "store")]
    Store,
}

Or add runtime validation in Config::load() to ensure only valid values are accepted.

[Ngha-Boris]

Issue: Store Strategy Always Returns true for should_provision_existing

The StoreProvisioningStrategy::should_provision_existing always returns true, which means the store will be checked on every renewal cycle regardless of whether the certificate is still valid.

Suggestion: Consider if this is the intended behavior. For store provisioning, you might want to:

1. Check if the file/storage content has changed (hash comparison)
2. Or add a TTL-based check to avoid unnecessary reloads
3. Or document why unconditional reloading is the desired behavior

Currently, this could cause unnecessary storage reads.