Consider lowering overall sampling frequencies

Problem Description

We can get away with much longer sampling interval for wallclock, reducing overhead and possibility for clash with the cpu profiler.

Wallclock profile should be fine with the sampling interval in order of 100s of ms

Implement the accompanying regression test:

• The number of samples collected during a test must correspond to the expected number of samples, based on frequency and the max number of threads we sample on a tick

  • since the number of threads eligible for profiling is determined by a context filter, we can assert only the upper bound on the samples: 1000/period(ms) * 16 (IIRC, 16 is the default number of threads we would pick in one sampler tick)
  • for an exact check, we would need to run in a mode where the context filter is not applied and we are getting full 16 threads sampled each tick

Limitations

The wallclock sampling frequency must be consistent across all wallclock engines (ASGCT, J9, JVMTI)

Acceptance Rules

• Default wallclock sampling period is 200ms
• The profiler configuration captured in JFR must show the expected period
• The number of samples collected during a test must correspond to the expected number of samples, based on frequency and the max number of threads we sample on a tick
  • since the number of threads eligible for profiling is determined by a context filter, we can assert only the upper bound on the samples: 1000/period(ms) * 16 (IIRC, 16 is the default number of threads we would pick in one sampler tick)
  • for an exact check, we would need to run in a mode where the context filter is not applied and we are getting full 16 threads sampled each tick

Auto-generated by ouroboros. Adversarial review: PASS.