feat: add timestamp and traceId to verification response

[binbin-li]

Description

What this PR does / why we need it:

Per discussion with @yizha1, we should add more info in the verification response and the error msg from contraint template to help users pinpoint related Ratify logs.

This PR adds timestamp and traceID in verification response to help users identity the failing request easily. And the default constraint template is updated to report the timestamp and traceID when validation fails.

Example:
When we get an error message from admission webhook in terminal:

Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [ratify-constraint] Time=2024-08-08T13:55:51.647024898Z, failed to verify the artifact: libinbinacr.azurecr.io/testcosign@sha256:f2502800f0663995420b13214a0d20eae1ec9a3c072f99c462cef0132a684556, trace-id: 57e4f5ac-7152-4a0b-b056-cf8a117398f5

We could search for traceID in Ratify logs:

And if we have ELK set up, traceID can be used to filter logs directly.

The verification response will also include traceID and timestamp fields:

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

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

Attention: Patch coverage is 83.33333% with 2 lines in your changes missing coverage. Please review.

Files	Patch %	Lines
internal/logger/logger.go	60.00%	1 Missing and 1 partial ⚠️

Files	Coverage Δ
httpserver/handlers.go	75.66% <100.00%> (+0.12%)	⬆️
httpserver/types.go	100.00% <100.00%> (ø)
internal/logger/logger.go	96.49% <60.00%> (-3.51%)	⬇️

[akashsinghal]

LGTM. Thanks for adding this