WAL iterator's nextImpl implements performance problems caused by inaccurate semantics

> Note: Please use Issues only for bug reports. For questions, discussions, feature requests, etc. post to dev group: https://groups.google.com/forum/#!forum/rocksdb or https://www.facebook.com/groups/rocksdb.dev

### Expected behavior
When the consumer WAL log encounters the latest Sequence Number, the status of the iterator should be OK, not "tryagain".

### Reason
This kind of consumption WAL log speed catch up with the latest Sequence scene. If it is returned to "TRYAGAIN", according to semantics, a new WAL iterator must be allocated (because it cannot be distinguished by key, or other situations, so), when WAL When the file is large, this will lead to a large part of the WAL log from scanning, plus CRC32C computing, resulting in a large delay in the production environment.

### Actual behavior
When the consumer WAL log encounters the latest serial number, the state of the iterator returns "TRYAGAIN".

### Steps to reproduce the behavior