journal: optimize iteration by returning previously found candidate entry

In next_beyond_location() when the JournalFile's location type is
LOCATION_SEEK, it means there's nothing to do, because we already have
the location of the candidate entry. Do an early return. Note that now
next_beyond_location() does not anymore guarantee on return that the
entry is mapped, but previous patches made sure the caller does not
care.

This optimization is at least as good as "journal: optimize iteration:
skip files that cannot improve current candidate entry" was.

Timing results on my workstation, using:
$ time ./journalctl -q --since=2014-06-01 --until=2014-07-01 > /dev/null

Before "Revert "journal: optimize iteration: skip files that cannot
improve current candidate entry":

real    0m5.349s
user    0m5.166s
sys     0m0.181s

Now:

real    0m3.901s
user    0m3.724s
sys     0m0.176s

1 files changed, 6 insertions, 0 deletions

diff --git a/src/journal/sd-journal.c b/src/journal/sd-journal.c
index 0aaf2257d4..0fefe2bc6e 100644
--- a/src/journal/sd-journal.c
+++ b/src/journal/sd-journal.c
@@ -742,6 +742,12 @@ static int next_beyond_location(sd_journal *j, JournalFile *f, direction_t direc
         f->last_n_entries = n_entries;
 
         if (f->last_direction == direction && f->current_offset > 0) {
+                /* LOCATION_SEEK here means we did the work in a previous
+                 * iteration and the current location already points to a
+                 * candidate entry. */
+                if (f->location_type == LOCATION_SEEK)
+                        return 1;
+
                 cp = f->current_offset;
 
                 r = journal_file_move_to_object(f, OBJECT_ENTRY, cp, &c);