Don't fail the whole request on an unparseable log entry

[MoheyElbaz]

Fixes #529. Replaces #532, which I closed because my own patch had three defects in it.

LaravelLog::parseText() reads $matches[1] straight after preg_match without checking whether it matched:

preg_match(static::regexPattern(), array_shift($firstLineSplit), $matches);

$this->datetime = Carbon::parse($matches[1])?->setTimezone(LogViewer::timezone());

When the chunk isn't a Laravel entry — the reporter had a run of null bytes from a partial write on a shared volume — $matches is empty, Laravel turns the undefined key into an ErrorException, and /log-viewer/api/logs returns a 500 for the whole file rather than for the one bad entry.

There are two ways into that crash, not one

The pattern is stricter than the one that indexed the entry. regexPattern() demands \d{6} for fractional seconds and is anchored at ^\[, while Log::matches() accepted the entry using the looser static::$regex. Both of these match $regex and fail regexPattern():

[2022-08-25 11:16:17.123] local.ERROR: boom      millisecond precision
 [2022-08-25 11:16:17] local.ERROR: boom         anything before the '['

And a matched timestamp can still throw. regexPattern() uses bare \d{2} for month, day and hour, so [2022-13-45 11:16:17] local.ERROR: x matches and Carbon::parse() then raises DateMalformedStringException — the same whole-request failure by a different route. There are tests for both.

What this does

On either failure, fall back to static::$regex and keep the datetime, level and environment it finds. Only content matching neither is marked unparseable, with no severity and the printable part of its first line as the message.

Three details that matter:

• The fallback works from the same 1000-char chunk the strict branch matches against. The remainder of a long first line is appended back further down, so handing the fallback the whole $firstLine writes its tail twice — a 2500-char line renders 1500 characters duplicated. That was a bug in Don't fail the whole request on an unparseable log entry #532; there is now a test for it.
• It returns into the shared code path, so the maxLogSize() cap and the first-line-only message still apply. An early return instead left unparseable entries uncapped at 600,021 bytes with log_text_incomplete unset, and put the entire entry in message.
• Control bytes are stripped as \p{Cc}, not \p{C}. The wider class also takes Cf, which includes the bidi marks that keep mixed Arabic and Latin log lines in the right order and the zero-width joiner that holds emoji sequences together. Also a bug in Don't fail the whole request on an unparseable log entry #532, also now tested.

I left IndexedLogReader::next() alone: its empty($text) check returns null, which ends iteration rather than skipping, so changing it there would silently truncate log lists.

Tests

15 cases added to LaravelLogsTest — the corrupt shapes, the unreadable timestamps, the loose-pattern recovery, the duplication, the message bound, the bidi marks, the size cap, and that a valid entry is untouched.

main       337 passed (1038 assertions)
this PR    352 passed (1077 assertions)
pint       passed

14 of the new cases fail against main.