Draft: WIP: MariaDB ability to run past 2038

Currently it is impossible to start MariaDB on a system with date set past 2038:

$ date
Thu Mar  3 05:55:28 UTC 2039
$ ./sql/mariadbd --version
2039-03-03  5:58:55 0 [ERROR] This server doesn't support dates later than 2038

This is due to https://github.com/MariaDB/server/blob/11.5/sql/mysqld.cc#L3903-L3908

/* TODO: remove this when my_time_t is 64 bit compatible */
  if (!IS_TIME_T_VALID_FOR_TIMESTAMP(server_start_time))
  {
    sql_print_error("This server doesn't support dates later than 2038");
    exit(1);
  }

This MR has patch to remove those lines, but once removed, MariaDB runs a bit further but fails to fully start, despite building and running it on latest Debian unstable with all latest libc and other updates that are supposed to have full 64-bit time_t support:

$ date
Thu Mar  3 06:26:07 UTC 2039
$ ./sql/mariadbd --version
./mariadbd  Ver 10.11.7-MariaDB-3 for debian-linux-gnu on x86_64 (Debian n/a)
$ ./mtr --force --parallel=auto --vardir=$(mktemp -d) --big-test | tee test-2039.log
Checking supported features...
390303  6:26:08 [ERROR] mysqld got signal 11 ;
Sorry, we probably made a mistake, and this is a bug.

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.

Server version: 10.11.7-MariaDB-3 source revision: 53b2e79983a40e8121c6bcf8c14f1254d4ed7417
key_buffer_size=0
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 336988 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x49000
mysys/stacktrace.c:216(my_print_stacktrace)[0x5628783e0c82]
sql/signal_handler.cc:238(handle_fatal_signal)[0x562877f38639]
/lib/x86_64-linux-gnu/libc.so.6(+0x3c510)[0x7f574253c510]

This has been briefly discussed in https://lists.mariadb.org/hyperkitty/list/developers@lists.mariadb.org/thread/Y4CKCBJ2YYHB4HNJVIEJEEEC4IUY4ZXB/ and the main upstream issue seems to be MDEV-32188: make TIMESTAMP use whole 32-bit unsigned range, but it is blocked by MDEV-33449: improving repair of tables. It is unclear if there are other issues - the original main issue MDEV-9444: MariaDB needs to be Y2038-compliant is void of any research and was closed as duplicate of MDEV-32188 as if there are no other issues.

We know that 32-bit systems need special workarounds to support time_t (as done in !68 (merged) with 81945443 and d2a0784f), but that is not enough as currently no version of MariaDB, not even n 64-bit systems, support running past 2038 at all.

When MariaDB is started on a system running in date set to 2037 there are also a lot of test failures due to other time related issues (see attached test-2037.log). When running tests in 2038 they fail completely (test-2038.log).

To get 2038 support, we most likely need:

1. Extend GitLab CI with a job that runs mariadb-test-run in 2037 to show which tests in general are incompatible with 10+ years of future time, and fix them first.
2. Extend GitLaB CI with a job that runs mariadb-test-run in 2038 to further show which tests fail specifically because of the year 2038 problem.
3. Then iterate and fix until both jobs pass.