journalctl: don't trust the per-field entry tables when looking for boot IDs

journalctl: don't trust the per-field entry tables when looking for boot IDs

When appending to a journal file, journald will:

a) first, append the actual entry to the end of the journal file
b) second, add an offset reference to it to the global entry array stored at
   the beginning of the file
c) third, add offset references to it to the per-field entry array stored at
   various places of the file

The global entry array, maintained by b) is used when iterating through the
journal without matches applied.

The per-field entry array maintained by c) is used when iterating through the
journal with a match for that specific field applied.

In the wild, there are journal files where a) and b) were completed, but c)
was not before the files were abandoned. This means, that in some cases log
entries are at the end of these files that appear in the global entry array,
but not in the per-field entry array of the _BOOT_ID= field. Now, the
"journalctl --list-boots" command alternatingly uses the global entry array
and the per-field entry array of the _BOOT_ID= field. It seeks to the last
entry of a specific _BOOT_ID=field by having the right match installed, and
then jumps to the next following entry with no match installed anymore, under
the assumption this would bring it to the next boot ID. However, if the
per-field entry wasn't written fully, it might actually turn out that the
global entry array might know one more entry with the same _BOOT_ID, thus
resulting in a indefinite loop around the same _BOOT_ID.

This patch fixes that, by updating the boot search logic to always continue
reading entries until the boot ID actually changed from the previous. Thus, the
per-field entry array is used as quick jump index (i.e. as an optimization),
but not trusted otherwise.  Only the global entry array is trusted.

This replaces PR #1904, which is actually very similar to this one. However,
this one actually reads the boot ID directly from the entry header, and doesn't
try to read it at all until the read pointer is actually really located on the
first item to read.

Fixes: #617
Replaces: #1904