docs: add a proposal for periodic retrieval

[yizha1]

Description

What this PR does / why we need it:

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):

This is the proposal for issue #1131

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

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

[susanshi]

Hi @duffney, Yi's have proposed the desired experience for KMP refresh. Please review and comment, thanks!

[yizha1]

Thanks @susanshi @bureado @binbin-li @akashsinghal for comments. I am updating the PR now and will ask for another round of review soon.

[yizha1]

@susanshi @bureado @binbin-li @akashsinghal @shizhMSFT @duffney would you mind reviewing this PR again. We can walk through the comments during community meetings. I updated this PR by adding comparison for various KMS, and add a section for proposed solutions by comparing two methods.

[akashsinghal]

@yizha1 have we thought about scenarios where a user misconfigures the certificate permissions or provides the wrong reference. In this case, how should Ratify respond? Should it immediately start to fail signature validation or do we need some sort of "pre check" so that a misconfiguration doesn't accidentally block resource creation. OR is it ok if user errors results in potential resource creation blocking.

[yizha1]

@susanshi @akashsinghal would you mind reviewing this PR again?

[akashsinghal]

Thanks for addressing all comments! lgtm

[susanshi]

LGTM. thanks Yi!