vinyl: do not handle restore in next_key/next_lsn callbacks

Not only restore() callback can restore the iterator position after the
source changed - next_key() and next_lsn() can do that too, which brings
additional complexity. Do we really need it? Not really:

 - We can avoid handling restoration in next_key() by simply calling
   restore() before it. This is cheap as restore() is a no-op if the
   source was not changed.

 - Regarding next_lsn() - when it comes to calling it, we iterate over
   sources from the most recent one to the oldest, which means that the
   only sources out there that may yield, on-disk runs, are guaranteed
   to be iterated last, after all mutable sources (txw, cache, mems), so
   none of the mutable sources needs to be restored in this case.

Simplify the read iterator as per above.