For Linux we test if we can use `CLOCK_THREAD_CPUTIME_ID` but not the clocks supported by `pthread_getcpuclockid()`.

The following comment has been around for at least 18 years according to the git commit history (points to the initial git commit from Dec 1, 2007):

```
// Switch to using fast clocks for thread cpu time if
// the sys_clock_getres() returns 0 error code.
// Note, that some kernels may support the current thread
// clock (CLOCK_THREAD_CPUTIME_ID) but not the clocks
// returned by the pthread_getcpuclockid().
// If the fast Posix clocks are supported then the sys_clock_getres()
// must return at least tp.tv_sec == 0 which means a resolution
// better than 1 sec. This is extra check for reliability.
```

There was a time when the Linux kernel did not provide an implementation for `CLOCK_THREAD_CPUTIME_ID` (that arrived with v2.6.12). During this period, glibc emulated support for `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` in userspace for the current thread only. `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` will call `pthread_getcpuclockid` in https://elixir.bootlin.com/glibc/glibc-2.2.5/source/linuxthreads/sysdeps/pthread/getcpuclockid.c. The checks and comment exists because `CLOCK_THREAD_CPUTIME_ID` worked (via emulation) but `pthread_getcpuclockid()` failed.

During that period of the early 2000s this check was indeed needed. But now sufficient time has passed and we don't support OpenJDK for that old kernel versions/glibc. Therefore, this check should be removed and some code can be cleaned up.