Improve clarity of error messaging

[cmaclaughlin]

Although there is a lot to like about the rego policy provider, it isn't always obvious what went wrong and why the workload was denied.

I've been using the logs (kubectl logs -l app.kubernetes.io/name=ratify --namespace gatekeeper-system --tail 100) for this purpose and found that the current error handling - specifically nested/wrapped errors - are hard to read.

Given the scenario where the x509 subject of the signing cert. does not match a configured trusted identity:

Currently, each failed notation verifier result has this message:

"message": "Original Error: (Original Error: (signing certificate from the digital signature does not match the X.509 trusted identities [map[\"C\":\"US\" \"CN\":\"pipeline.example.com\" \"L\":\"Redmond\" \"O\":\"My Company\" \"OU\":\"My Org\" \"ST\":\"WA\"]] defined in the trust policy \"default\"), Error: verify plugin failure, Code: VERIFY_PLUGIN_FAILURE, Plugin Name: verifier-notation, Component Type: verifier, Documentation: https://ratify.dev/docs/troubleshoot/verifier/notation, Detail: failed to verify signature of digest), Error: verify reference failure, Code: VERIFY_REFERENCE_FAILURE, Plugin Name: verifier-notation, Component Type: verifier",

The only error that is meaningful is the original (original?) error signing certificate from the digital signature does not match the X.509 trusted identities.... The only thing that might be nice is what the actual value is - clearly it isn't in the trusted list -- this isn't a hard requirement by any means though.

VERIFY_PLUGIN_FAILURE leads me to think that the configuration is wrong, or something else is programmatically wrong with the verifier in question. Especially since there is a link to the docs!

VERIFY_REFERENCE_FAILURE is also potentially misleading. 

[akashsinghal]

Thanks @cmaclaughlin for pointing this out. I agree the nested error codes are very confusing for debugging. We plan to revisit this in this next release. @yizha1 I think we should incorporate this feedback for this issue: #1321