Assertion `!ShouldScheduleFlush()' failed when constructing a memtable.

Recently I used YCSB to do some database benchmarking. I tried to change some default options, when I changed write_buffer_size to 2M, the database always made an error when construct Memtable.
### Expected behavior
Execute the constructor of Memtable correctly.
### Actual behavior
**Error:**/rocksdb/db/memtable.cc:117: rocksdb::MemTable::MemTable(const rocksdb::InternalKeyComparator&, const rocksdb::ImmutableOptions&, const rocksdb::MutableCFOptions&, rocksdb::WriteBufferManager*, rocksdb::SequenceNumber, uint32_t): Assertion `!ShouldScheduleFlush()' failed.

When a Memtable is constructed, the state of flush_state_ will be checked first, which cannot be FLUSH_REQUESTED.
However, in the previous UpdateFlushState(), since ShouldFlushNow() returned true, flush_state_ was set to FLUSH_REQUESTED, which caused it to fail in the asset below.
I read the source code of ShouleFlushNow() carefully, when I debug to this function, the kArenaBlockSize is 16M and the write_buffer_size is 2M. ShouldFlushNow() will not return through the following two logics.
Instead return the result with this line of code at the end. I noticed the comment, which states that this means Arena has already allocated his "last block". At this time, my arena_.AllocatedAndUnused() is 1384, which is much smaller than 0.25*kArenaBlockSize.
### Steps to reproduce the behavior
Simply, just set write_buffer_size to 2M or less, or a slightly larger number.(:

Start by reproducing the failure with write_buffer_size set to 2M or less. Read db/memtable.cc around the MemTable constructor, UpdateFlushState(), and ShouldFlushNow(), then trace why FLUSH_REQUESTED persists into construction. Done means the constructor completes without the assertion for the reported configuration and the behavior is covered by an appropriate regression check.

Written by the indexing model from the issue text.