Bar, please review bb-11.3-monty

monty, there is a summary of my review comments (previously discussed on slack):

• This code is going to change under terms of MDEV-32496 and MDEV-10018. Therefore, it's better to take into account planned changes, to stabilize the underlying code one time instead of two times.

• I don't like that you use a differently defined my_time_t on different platforms. If you want to preserve my_time_t for plugin compatibility, then the server code should use a different data type. Let's call it for example my_seconds_t, and it should be defines as longlong (signed).

• This new data type for seconds should be a part of ABI.

• The type my_time_t should not be touched, and it should stay in ABI. I don't like that you removed it. I think this is meaningless to remove my_time_t from ABI but insist that we need it for backward compatibility.

• The data type in most server files should be changed from my_time_t to my_seconds_t. Functions/methods which depend on my_time_t that you want still to be available for plugings should be duplicated: for my_time_t and for my_seconds_t.

• my_timeval should be changed as follows:

  struct my_timeval

  {

  longlong tv_sec; -- change to my_seconds_t

  long tv_usec; -- change to uint32

  };

• To convert between my_seconds_t and MYSQL_TIME on more 32bit systems, we should add a CMake check for functions localtime64_r (Unix) and locatime64_s (Windows) and use these functions when available.

The patches in bb-11.3-monty are Ok to push.
I'd still prefer though if we used a system independent replacement for my_time_t.

The branch is now bb-11.4-timestamp.

I encountered the changeset Updated ALTER TABLE to convert old row_end timestamps to new timestamp range that is related to this task. I think that a change of a data type (from unsigned 31-bit timestamps to unsigned 32-bit) needs to be signaled to the storage engines by setting the ALTER_STORED_COLUMN_TYPE flag. In that way, InnoDB will refuse to perform any native ALTER TABLE operation just fine, and any fixup attempts like this one should be unnecessary. The idea of handler::check_if_supported_inplace_alter() is to let the storage engine choose the most efficient algorithm, unless the user has instructed otherwise, by specifying ALGORITHM=COPY or setting the parameters old_alter_table=1 or (ever since MDEV-13134) alter_algorithm=copy.

The ALTER TABLE attribute FORCE was originally introduced in MySQL 5.6.17 by the following bug fix, to allow the MySQL 5.6.8 WL#6255 online table rebuild to work on OPTIMIZE TABLE:
BUG# 13975227: ONLINE OPTIMIZE TABLE FOR INNODB TABLES
The idea is that OPTIMIZE TABLE will map to ALTER TABLE…FORCE in the case that handler::optimize() is not implemented or supported in the storage engine.

I do not know which was the first GA release of MariaDB Server 10.0, but I think that this change was part of that release series from rather early on.