fix(bigtable): Use a different t4t7 latencies for directpath

[sushanb]

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)
• Rollback plan is reviewed and LGTMed
• All new data plane features have a completed end to end testing plan

Fixes #<issue_number_goes_here> ☕️

If you write sample code, please follow the samples format.

[igorbernstein2]

Why not a volatile Stopwatch? it would communicate the intent better:

  volatile Optional<Stopwatch> faket4t7 = Optional.empty();

public void grpcHeadersSent() {
  faket4t7 = Optional.of(Stopwatch.createStarted());
}

public void grpcHeadersReceived() {
  faket4t7.map(Stopwatch::stop);
}

recordAttemptCompletion() {
  if (sidebandData.getGfeTiming() != null) {
  } else if (faket4t7.isPresent()) {
     ....
  }
}
....

[igorbernstein2]

This is expanding scope to what we talked about. This was supposed to be only for DirectAccess. This implementation expands the scope to any time the header is missing. Which means that we wont be able to tell what we are actually measuring. In our original conversation scoping it only to DA, we could reason that when transport_type is DA, we measuring client headers until response headers. In all other cases we are measuring gfe latency. And if the DistributionCount() drops we know that we couldnt reach a gfe. With this approach, we muddy our ability to reason about the metric