The `NightlyFuzzers` run at 8d8dd30 failed with
two findings.

`data_type_deserialization_fuzzer` ran out of memory (used 8235 Mb, limit 8192 Mb)
with 5.5 GB of live heap in `DateLUT::getImplementation`. `cctz` synthesizes a zone
for every name of the form `Fixed/UTC±HH:MM:SS` without consulting the time zone
database, and accepts any offset up to 24 hours, which is 172801 distinct names.
Every name that gets loaded permanently costs ~4.6 MiB in the `DateLUT` cache, and
that cache never evicts anything because callers keep bare references into it, so
untrusted input could make the server allocate memory that it never gives back:
1 name costs 187 MB of RSS, 180 names cost 989 MB, 600 names cost 2964 MB.

Accept only the offsets a time zone can actually have: a whole number of quarters
of an hour, no further from UTC than 14 hours. That covers every offset in the time
zone database - the last one that was not a multiple of 15 minutes ended in 1972 -
and leaves 113 such names, which bounds the cache. `Values::OffsetChangeFactor`
already assumes the same granularity for the offset changes within a zone. The
`session_timezone` setting validates through the same predicate, so a value cannot
be accepted and then fail on every query.

`select_parser_fuzzer` hit its 60 second per-input timeout while still replaying its
own corpus. Its seed corpus is generated from `tests/queries`, whose largest file is
~380 KB, and without an explicit `max_len` libFuzzer sizes every input after that
file. The 334 KB input it timed out on parses in 0.28 s of CPU in a release build,
so nothing is wrong with the parser - a query that long just cannot be parsed within
60 seconds by a sanitizer build. Cap the input length at 65536, the same cap
`create_parser_fuzzer` already uses.

The statistics the report printed for both targets were nonsense - "replaying the
initial corpus took 19701 of 140 executed inputs (14072%), leaving -19561 mutations".
`parse_libfuzzer_output` split each line before testing it, which strips indentation,
so the frames of a sanitizer stack trace were taken for libFuzzer progress lines and
the last frame's depth was reported as the number of executed inputs. Anchor the
progress line at the start of the line and require its event to be a word: the run
above then reports 34930 executed inputs with the rest of its statistics intact.

Report: https://s3.amazonaws.com/clickhouse-test-reports/praktika.html?REF=master&sha=8d8dd308b73c4bb8ef921f0b01f6806656054872&name_0=NightlyFuzzers&name_1=libFuzzer%20tests

Related: #107459