[KMSv2] log request metadata as part of read/write

[aramase]

What type of PR is this?

/kind feature

What this PR does / why we need it:

• Logs additional metadata as part of transform to_storage and from_storage.

Which issue(s) this PR fixes:

Fixes #111923

Special notes for your reviewer:

Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[KEP] https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3299-kms-v2-improvements

[aramase]

/sig auth
/triage accepted
/priority important-soon

/assign @enj

[enj]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aramase, enj

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• staging/src/k8s.io/apiserver/pkg/storage/value/OWNERS [enj]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[enj]

/lgtm cancel

Looks like CI linting doesn't like building arguments. Maybe create a separate function that returns a default request info if it's not present? So the actual log statement would be able to use it unconditionally?

[aramase]

/lgtm cancel

Looks like CI linting doesn't like building arguments. Maybe create a separate function that returns a default request info if it's not present? So the actual log statement would be able to use it unconditionally?

done!

[enj]

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: d353a3ac0e526e4a148483c0fb03ddb78bc0b2e8

[sftim]

I think users could observe the outcome of this merge. Where'll we changelog it?