feat: Implementation of KMP CRL revocation factory with cache

[junczhu]

Description

What this PR does / why we need it:

Enabled load CRLs from all types of KMP provider, both inline KMP and akv KMP.
Optimized CRL core functions and the Implementation of CRL Handler, CRL Handler is now the only implementation of the CRL interface and being reused by notation verifier and KMP.
Added description to the interface definition and more comments to the codebase.

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 #1901

Optimize CRL interface and core functions:

Implementation of CRL Handler

Design Doc: https://github.com/ratify-project/ratify/blob/dev/docs/design/Certificate%20Revocation%20Lists.md

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?

CI test

Checklist:

• Does the affected code have corresponding tests?
• [TBD] 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

[binbin-li]

since the prev PR got merged, we can switch the target branch to dev.

[junczhu]

since the prev PR got merged, we can switch the target branch to dev.

As discussed, I can keep target as feature branch till we have e2e ready.
test cov and CI tests results would be checked in my fork.

[junczhu]

As discussed, I would include the CacheCRL as part of the KMP function and use the current one as a basic implementation.

[junczhu]

As discussed, I would include the CacheCRL as part of the KMP interface for different provider can

As discussed, I would include the CacheCRL as part of the KMP function and use the current one as a basic implementation.

Done

[codecov]

Codecov Report

Attention: Patch coverage is 91.66667% with 6 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
pkg/verifier/notation/revocationfactory.go	85.00%	4 Missing and 2 partials ⚠️

Files with missing lines	Coverage Δ
pkg/keymanagementprovider/refresh/kubeRefresh.go	100.00% <100.00%> (ø)
pkg/verifier/notation/notation.go	98.06% <100.00%> (+0.01%)	⬆️
pkg/verifier/notation/notationrevocationfactory.go	86.95% <100.00%> (+13.04%)	⬆️
pkg/verifier/notation/revocationfactory.go	85.00% <85.00%> (ø)

... and 3 files with indirect coverage changes