Appender's resetPosition uses approximate last sequence number

[alamar]

Found when debugging ChronicleEnterprise/Chronicle-Queue-Enterprise#333

StoreAppender.writeBytesInternal() will call resetPosition every time (which may be wasteful), but it will also assign wire.headerNumber to store.approximateLastSequenceNumber, which is as its name implies approximate, and may return invalid value when queue is closed after process crash.

This does not seem optimal, but for some reason store.exactLastSequenceNumber call is prohibitively expensive to be used there. In many cases it would resort to sequential scanning of queue, which should be almost always unnecessary.

If this problem is fixed then check introduced in ChronicleEnterprise/Chronicle-Queue-Enterprise#333 may be removed.

[yevgenp]

Is it still an issue after @nicktindall fixed https://github.com/OpenHFT/Chronicle-Queue/issues/1538 ? There is no store.approximateLastSequenceNumber anymore.

[nicktindall]

All calls to lastSequenceNumber while holding a read lock should be accurate after #1537. There's no approximate/exact anymore.