RFR: 8351146: JFR: Reconsider thresholds for monitor-related events

[Aleksey Shipilev]

There are two issues with current thresholds for monitor-related events:

 1. The threshold for enter/wait is too high for practical use. @coleenp separately said during related CSR review that 5ms is more practical value: https://bugs.openjdk.org/browse/JDK-8348833?focusedId=14744853#comment-14744853 -- I think we should trim those even further.
 
 2. There is a threshold for inflate event. But the operation that is covered by that event is very fast, and often lock-free, so the threshold would filter many events. This would be important as we add deflation event ([JDK-8351142](https://bugs.openjdk.org/browse/JDK-8351142)), which should match inflations.

The PR changes `locking-threshold` default, so it affects a few other events as well. I am picking 1ms as the practical value that we usually deal with in production environments, as we chase down single-digit-ms latency hogs. I am open for suggestions about the values, though. Maybe `default.jfc` values should be higher?

Additional testing:
 - [x] Linux x86_64 server fastdebug, `jdk_jfr` still passes

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/23891/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23891&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351146
  Stats: 12 lines in 2 files changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/23891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23891/head:pull/23891

PR: https://git.openjdk.org/jdk/pull/23891