Add active_record.config.validate_migration_timestamps config option.

[adrianna-chang-shopify]

Motivation / Background

Take two of #50205, reverted here.

As discussed in the revert PR, forward-dated migrations are the main reason hand-edited migrations can be problematic.
Rather than validating that a timestamp is a "real" timestamp in the form we expect, as proposed in the first PR, we reject any migrations with timestamp prefixes greater than "one day from the current timestamp". The 1.day allows us to forward date migrations within a narrow range, when e.g. copying engine migrations, while preventing prefixes that would actually pose problems for future migration generation.

Detail

Adds an active_record.config.validate_migration_timestamps config option. When set, an ActiveRecord::InvalidMigrationTimestampError will be raised if the timestamp prefix for a migration is more than a day ahead of the timestamp associated with the current time. This is done to prevent forward-dating of migration files, which can impact migration generation and other migration commands.

It is turned off by default, but will be turned on for applications starting in Rails 7.2.

Additional information

There was some discussion in #50231 about string vs numeric based maxes. We are inconsistent with which one we use: #next_migration_version uses a string-based max:

rails/activerecord/lib/active_record/migration.rb

Lines 1118 to 1120 in b0048c7

	def next_migration_number(number)
	if ActiveRecord.timestamped_migrations
	[Time.now.utc.strftime("%Y%m%d%H%M%S"), "%.14d" % number].max

But #current_version uses a numeric one:

rails/activerecord/lib/active_record/migration.rb

Lines 1302 to 1305 in b0048c7

	def current_version # :nodoc:
	get_all_versions.max || 0
	rescue ActiveRecord::NoDatabaseError
	end

For the purposes of this PR, I believe we should compare using numeric-based maxes: this ensures that migration prefixes that are too long (ie. more than 14 digits) will be flagged as invalid. There was a previous PR that changed #next_migration_version to use an integer-based maxed, but it was reverted because it broke existing migrations with timestamps that were too long (one of the cases we're trying to prevent with this PR). We may want to consider bringing in those changes so that we consistently assume "current migration" to mean "migration with numeric-based max version".

It's also worth noting that it's hard for existing applications to opt-into this if they already have problematic migrations (as we do at Shopify). Should we enforce that applications roll these migrations up, or modify the filenames?

Checklist

Before submitting the PR make sure the following are checked:

• This Pull Request is related to one change. Changes that are unrelated should be opened in separate PRs.
• Commit message has a detailed description of what changed and why. If this PR fixes a related issue include it in the commit message. Ex: [Fix #issue-number]
• Tests are added or updated if you fix a bug or add a feature.
• CHANGELOG files are updated for the changed libraries if there is a behavior change or additional feature. Minor bug fixes and documentation changes should not be included.

cc @eileencodes @matthewd @fxn

[eileencodes]

This looks good to me. Can you fix the conflicts and then I'll merge?

[adrianna-chang-shopify]

Done, thanks @eileencodes !