Changed names as h2o/h2o#2053 (comment) suggested.

I already use clock_gettime(CLOCK_REALTIME, ...) here 😉

@syohex san suggested we can use C++ standard library for this purpose. https://twitter.com/syohex/status/1253527261896032256

I like this PR as-is because it's an idiomatic use of the POSIX clock_gettime(). That said, this is a very hot code path. If std::chrono gives us perf benefits, I have no objections to using it.

If std::chrono gives us perf benefit

I suppose there is no performance benefit. Because std::chrono API is only wrapper function of clock_gettime on Unix like system. For example std::chrono::system_clock::now implementation is below. This increases some function/constructor calls overhead. I suppose they are inlined by compiler optimization however more instructions are necessary rather than calling clock_gettime directly.

  struct timespec tp;
  if (0 != clock_gettime(CLOCK_REALTIME, &tp))
    __throw_system_error(errno, "clock_gettime(CLOCK_REALTIME) failed");
  return time_point(seconds(tp.tv_sec) + microseconds(tp.tv_nsec / 1000));

Skew from not using the server time does sound real. This brings up another topic that it looks like we stopped using quicly's at/time value at some point.

Please dismiss my comment from above. We do use at where possible from quicly. I had forgotten that there are non-quicly probes in the QUIC tracer.

Thanks to @kazuho, I've realized there are two problems with this PR:

1. CLOCK_REALTIME is not suitable to keep the exact order, so we have to use another stuff for sorting
2. CLOCK_REALTIME is not what exactly quicly emits, so we have to use at field as a timestamp

Considering another way.