feat: update crds and default templates

[junczhu]

Description

What this PR does / why we need it:

• [ ] Enable KMP CRL config input in CRDs.
• [ ] Update default templates

Which issue(s) this PR fixes (optional, using fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when the PR gets merged):

Fixes # 1888

Objective Ensure the overall user experience of the CRL feature is consistent.

1. Ratify Preload Workflow (kmp) 1.1 Verify the AKV provided certificate chain (in the same team pub-sub scenario to ensure the full cert chain is included); inline holds only the root cert as a verifier; notation retrieves the chain from the signature.
   • [*] AKV, implemented in 1.4.0
   • Inline, not included in this feature
   • (Going to create New Issue to track) Manual/raw byte/distributed point URL input [Azure integration]

1.2 Feature flag about caching: Ratify close cache, notation revocation check cache, align notation trust policy with the notation config.

• Need to discuss with the notation team

2. Handle Non-Manual Loading

   • Ensure non-manual loading processes, loading happening in the verifier, are aligned with CRL preloaded on purpose. This includes using the same configuration for fetcher and cache (refresher is optional as listed below).

3. Configuration Enhancements

   • [Nice to have] Expose fetcher timeout config, retry config, and set a default value for these configurations.

Questions

• What would be the default values for the timeout and retry configurations?

-----------------WHICH IS NOT PLANNED FOR 1.4.0------------------------

4. Refresh Configuration
   • Notation currently refreshes when CRLs are used and found to be expired. Should ratify set a period for regular checks?
   • [Optional] Also refresh notation download checks. If this is not implemented, the notation verifier would redo the check and download the new CRL. Since this is not on a critical path, mark it as optional.

Open Questions

• What would be an appropriate period for these regular checks?

Type of change

Please delete options that are not relevant.

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] Helm Chart Change (any edit/addition/update that is necessary for changes merged to the main branch)
• [ ] This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Please also list any relevant details for your test configuration

• [ ] Test A
• [ ] Test B

Checklist:

• [ ] Does the affected code have corresponding tests?
• [ ] Are the changes documented, not just with inline documentation, but also with conceptual documentation such as an overview of a new feature, or task-based documentation like a tutorial? Consider if this change should be announced on your project blog.
• [ ] Does this introduce breaking changes that would require an announcement or bumping the major version?
• [ ] Do all new files have appropriate license header?

Post Merge Requirements

• [ ] MAINTAINERS: manually trigger the "Publish Package" workflow after merging any PR that indicates Helm Chart Change

[junczhu]

cc\ @yizha1 @FeynmanZhou for a heads-up