Instrumentation API changes: TimeExtractor with Context idea

[mateuszrzeszutek]

Another part of #6014 (resolves #6014 maybe?)

The first commit contains the actual TimeExtractor changes, the second is an example of how the Timer class from #4514 could look like, using the new API.

[trask]

Throwing out a few of other ideas to discuss in today's SIG meeting.

• Add two new methods on Instrumenter below:

  • pros:
    • users don't need to deal with clocks/timers
    • it's not possible to change endTime, which is good since metrics doesn't support this
  • cons:
    • muddies the clean Instrumenter API with methods that are not very commonly used

    public Context markStartTime(Context parentContext, REQUEST request) {
      // put the current time into the parentContext and return it
    }
  
    public void startAndEndMarked(
        Context context, REQUEST request, @Nullable RESPONSE response, @Nullable Throwable error) {
      // get the start time
      // call start
      // call end
    }
  

• Add a single new method on Instrumenter:

    public void startAndEnd(
        Context context,
        REQUEST request,
        @Nullable RESPONSE response,
        @Nullable Throwable error,
        long startTimeNanos,
        long endTimeNanos) {
  
    }
  

• Add a known "Timer" context key (and associated Timer API) that the existing Instrumenter start and stop methods look for. Comparing to this PR:

  • pros:
    • can avoid customizing end time
  • cons:
    • more magical
    • requires checking for the "Timer" context key even in the common case where it's not used

• This PR, but without passing the REQUEST object

[mateuszrzeszutek]

Closing; we decided to make providing start/end time internal for now. I'll implement that in a separate PR.