Pull Request for Issue #26387 , datetime part.

The user ID part is done in PR #26745 (added missing workflow table to routine updateUserIds) .

Summary of Changes

This Pull Request (PR) removes the routine updateDates from the installation database model.

The routine is used to set datetime fields in database to current date and time if they are not null and not equal to the old nulldate, i.e. when something was inserted with a hard-coded creation time at new installation.

With recently merged PR's for the datetimes things the joomla.sql scripts have been changed so there is not any data inserted anymore with such hardcoded times. Instead of this, CURRENT_TIMESTAMP is used.

So the updateDates routine is not needed anymore for the core.

For custom installation SQL scripts like localise.sql or custom.sql which might be used by some customized installations, it is recommended to use CURRENT_TIMESTAMP too in SQL scripts, but it is preferred to insert new content using the appropriate PHP API like we do in our diverse sample data.

See also comments here #26399 (comment) and here #26399 (comment).

Testing Instructions

Attention: Do this only on a testing environment where your data can be thrown away.

Testers please report back in any case (success or failure) which kind of database (MySQL/MariaDB or PostgreSQL) you've used for testing. If you have several and enough time, please test with all of them.

1. Apply this PR on a clean, up-to-date 4.0-dev branch or latest nightly 4.0 build.
2. If using an existing installation, remove configuration.php and delete all database table of that installation in order to be ready for the next step.
3. Make a new installation.
4. Do not log in to backend after the installation has finished. This makes the test easier, otherwise after login you may have some datetime set to a later value than the one to be tested for.
5. Check in your database with tools like eg PhpMyAdmin for MySQL or PhpPgAdmin for PostgreSQL that in tables which are not empty all columns of type datetime (MySQL) or timestamp without time zone (PostgreSQL) have either value NULL or the date and time of installation in UTC, but not anything else in past or future. Such columns are eg all columns like created_time or modified_time (with different named here and there, but you will find them).

Expected result

All datetimes in database which don't allow null values have as value the date and time in UTC when the installation has been finished, ie there is no other fixed datetime given in past or future for columns like created_time or modified_time.

There is one exception the lastResetTime of users, which will be fixed when PR #26611 is merged.

Actual result

Same as expected, but one useless routine more in the installation database model.

Documentation Changes Required

Maybe somewhere inform developers of customized installations that they shall use CURRENT_TIMESTAMP in SQL scripts but better insert new content using the appropriate PHP API like we do in our diverse sample data.