refactor: refactor error handling

[binbin-li]

Description

What this PR does / why we need it:

1. Refactor most errors to a custom error struct.
2. Each error would have an error code for fast searching.
3. For plugin errors, there would be componentType indicating the plugin type, and pluginName indicating the plugin name, e.g. verifier as componentType, and notation-verifier as pluginName.
4. Add OriginalError so that we can trace the root error.
5. Add Stack so that we can debug the stack trace.
6. Add a doc listing all errors. More work need to be done in the future to have more information on debugging each error.

Design doc: https://hackmd.io/@H7a8_rG4SuaKwzu4NLT-9Q/HJ6bNe2c2

The exported error codes could be checked on pkg.go.dev, just like this: https://pkg.go.dev/github.com/distribution/distribution@v2.8.2+incompatible/registry/api/errcode#pkg-variables

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

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

I tested the error format in both add-on service and CLI tool.

1. Add-on service.
   The service log would look like:
   

2. CLI.
   

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

[akashsinghal]

Thanks for this quality work @binbin-li! Would it be possible to get a screenshot of what the new formatted logs look like? Same for the error message from GK and the CLI?

[codecov]

Codecov Report

Patch coverage: 55.80% and project coverage change: +0.72% 🎉

Comparison is base (ab7636f) 57.45% compared to head (8fab6bd) 58.17%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #956      +/-   ##
==========================================
+ Coverage   57.45%   58.17%   +0.72%     
==========================================
  Files          90       91       +1     
  Lines        5326     5447     +121     
==========================================
+ Hits         3060     3169     +109     
- Misses       1956     1964       +8     
- Partials      310      314       +4     

Files Changed	Coverage Δ
pkg/common/oras/authprovider/authprovider.go	44.11% <0.00%> (ø)
pkg/policyprovider/configpolicy/configpolicy.go	92.59% <0.00%> (ø)
pkg/referrerstore/factory/factory.go	56.92% <0.00%> (ø)
pkg/referrerstore/oras/cache.go	72.72% <0.00%> (ø)
pkg/verifier/factory/factory.go	60.93% <0.00%> (ø)
pkg/verifier/plugin/plugin.go	70.83% <0.00%> (ø)
httpserver/handlers.go	74.34% <7.14%> (ø)
.../common/oras/authprovider/k8secret_authprovider.go	15.68% <7.14%> (ø)
pkg/referrerstore/oras/oras.go	68.83% <20.00%> (ø)
...kg/common/oras/authprovider/authproviderfactory.go	62.85% <25.00%> (ø)
... and 14 more

... and 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[susanshi]

Thanks for this quality work @binbin-li! Would it be possible to get a screenshot of what the new formatted logs look like? Same for the error message from GK and the CLI?

thanks the sample errors in the images. Just to clarify , when do we add stack trace to errors ? stack trace is needed when something is wrong ( ratify code error) , i want to make sure when Ratify successfully run validation,we don't pass a stack trace on a bad image. Also if it is a configuration error, customer need to fix the configuration, but they won't need to investigate the code base

[susanshi]

this is a great improvement @binbin-li over our current message, left some comments.

[susanshi]

Looks great! lets sync on the TSG

[susanshi]

Looks great! lets sync on the TSG

[binbin-li]

Looks great! lets sync on the TSG

synced offline. thanks a lot for feedback @susanshi

[susanshi]

LGTM. thanks!