HDDS-10386. Introduce Metrics for deletekey operation in OM Service.

[muskan1012]

What changes were proposed in this pull request?

In this PR few performance metrics are introduced in OM Service for deleteKey operation.

Please describe your PR in detail: In this PR following metrics are introduced in OM service for delete key operation:

• deleteKeyFailureLatencyNs
• deleteKeySuccessLatencyNs
• deletekeyResolveBucketlinkLatencyNs
• deleteKeyAclCheckLatencyNs
• deleteKeyAclCheckAndResolveBucketlinkLatencyNs

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-10386

How was this patch tested?

Tested manually on the cluster.

[kerneltime]

@muskan1012 can you take a look at captureLatencyNs used in https://github.com/apache/ozone/pull/3780 for capturing the latency of operation call. This will help avoid the need to capture start and stop time in each piece of the code you are trying to measure.

[tanvipenumudy]

While capturing the latencies of checkKeyACLs and resolveBucketLink individual calls, you can directly wrap the calls under the captureLatencyNs block (as mentioned in the previous reviews).

For latency capture spanning across multiple lines of code (such as success/failure operation latencies), you can either use the same lambda function with the lines of code enclosed under the '{}' of the captureLatencyNs block (following code snippet), or it should also be okay to capture the individual timestamps (you can make a judgement from the readability perspective).

captureLatencyNs(metrics.getMetricLatencyNs(), () -> {
// lines of code to be included whose
// latency needs to be taken into account.
}

[muskan1012]

While capturing the latencies of checkKeyACLs and resolveBucketLink individual calls, you can directly wrap the calls under the captureLatencyNs block (as mentioned in the previous reviews).

For latency capture spanning across multiple lines of code (such as success/failure operation latencies), you can either use the same lambda function with the lines of code enclosed under the '{}' of the captureLatencyNs block (following code snippet), or it should also be okay to capture the individual timestamps (you can make a judgement from the readability perspective).

captureLatencyNs(metrics.getMetricLatencyNs(), () -> {
// lines of code to be included whose
// latency needs to be taken into account.
}

Same thing is happening in both resolveBucketLink and checkAcl, in both case we must need to declare volumeName and bucketName as final to use it with captureLatencyNs.