RFR: 8309067: gtest/AsyncLogGtest.java fails again in stderrOutput_vm

[Xin Liu]

This patch fixes the flaky test AsyncLogTest. The race condition only occurs in async 
logging mode in combination of BufferUpdater. BufferUpdater is introduced for testing 
only. It installs smaller buffers so test code can reliably observe messages dropped.
AsyncLog drops messages when the current buffer is overflown. 

In stdout/stderrOutput testcases, we used to mix test_asynclog_ls() and 
test_asynclog_drop_messages(). The later function uses BufferUpdater. As a result, log
messages distribute in both old buffer and new buffer. 

A race condition unfolds in the sequences. Thread names are in brackets.
1. [AsyncLogWriter] just calls write().
2. [Test] calls the constructor of BufferUpdater. It updates AsyncLogWriter->_buffer_staging.
3. [AsyncLogWriter] sees the latest _buffer_staging. It emits nothing. 
4. [Test] call the destructor of BufferUpdater. _buffer_staging resumes to 
the original buffer.
5. [AsyncLogWriter] is waken up from _lock.wait. It proceeds to swaps _buffer and _buffer_staging.
at this point, we lost the log messages in the original buffer. AsyncLogWriter was about to dump them
at 1.

Only stdout/stderrOutput testcases interleave the original buffer and small buffer. That's why
we only encounter flaky failures on them. It's up to the OS scheduling. 

To eliminate the race condition, we must ensure that all messages write after BufferUpdater.
test_asynclog_drop_messages() fuses test_asynclog_ls().

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

Commit messages:
 - 8309067: gtest/AsyncLogGtest.java fails again in stderrOutput_vm

Changes: https://git.openjdk.org/jdk/pull/16728/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16728&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309067
  Stats: 50 lines in 1 file changed: 18 ins; 17 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/16728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16728/head:pull/16728

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