Apart from specific versioning support, our tests should focus on the
behaviour of whatever version they're accompanying, regardless of when
they were written.

Application code should *not* do this.

This reverts commit 8246b593.

There was concern about this modifying the behavior of past migrations.
We're going to add an way to modify the migration generator instead.

It's often the case that you want to have an option that you cannot
specify at the database level, but want applied to *all* tables that you
create. For example, you might want to specify `ROW_FORMAT=DYNAMIC` to
not have to limit text columns to length 171 for indexing when using
utf8mb4. This allows an easy way to specify this in your database
configuration.

While this change affects both MySQL and MySQL2, the test only covers
MySQL2, as the legacy mysql adapter appears to always return ASCII
strings, and is tangential to what we're actually doing.

- key was a poor choice of name. A key implies something that will
  unlock a lock. The concept is actually more like a 'lock identifier'
- mysql documentation calls this a 'lock name'
- postgres documentation calls it a 'lock_id'
- Updated variable names to reflect the preferred terminology for the database in
  question

we should be using a countdown latch instead of rolling our own
busy-loop.

- Addresses issue #22092
- Works on Postgres and MySQL
- Uses advisory locks because of two important properties:
  1. The can be obtained outside of the context of a transaction
  2. They are automatically released when the session ends, so if a
  migration process crashed for whatever reason the lock is not left
  open perpetually
- Adds get_advisory_lock and release_advisory_lock methods to database
  adapters
- Attempting to run a migration while another one is in process will
  raise a ConcurrentMigrationError instead of attempting to run in
  parallel with undefined behavior. This could be rescued and
  the migration could exit cleanly instead. Perhaps as a configuration
  option?

Technical Notes
==============

The Migrator uses generate_migrator_advisory_lock_key to build the key
for the lock. In order to be compatible across multiple adapters there
are some constraints on this key.
- Postgres limits us to 64 bit signed integers
- MySQL advisory locks are server-wide so we have to scope to the
  database
- To fulfil these requirements we use a Migrator salt (a randomly
  chosen signed integer with max length of 31 bits) that identifies
  the Rails migration process as the owner of the lock. We multiply
  this salt with a CRC32 unsigned integer hash of the database name to
  get a signed 64 bit integer that can also be converted to a string
  to act as a lock key in MySQL databases.
- It is important for subsequent versions of the Migrator to use the
  same salt, otherwise different versions of the Migrator will not see
  each other's locks.

The last call site of `last_version` was removed with:

838e1832

Remove `MigrationTest#connection` and write `ActiveRecord::Base.connection`
directly to test, because `MigrationTest#connection` is only used in
`test_migration_instance_has_connection`.

I’m renaming all instances of `use_transcational_fixtures` to
`use_transactional_tests` and “transactional fixtures” to
“transactional tests”.

I’m deprecating `use_transactional_fixtures=`. So anyone who is
explicitly setting this will get a warning telling them to use
`use_transactional_tests=` instead.

I’m maintaining backwards compatibility—both forms will work.
`use_transactional_tests` will check to see if
`use_transactional_fixtures` is set and use that, otherwise it will use
itself. But because `use_transactional_tests` is a class attribute
(created with `class_attribute`) this requires a little bit of hoop
jumping. The writer method that `class_attribute` generates defines a
new reader method that return the value being set. Which means we can’t
set the default of `true` using `use_transactional_tests=` as was done
previously because that won’t take into account anyone using
`use_transactional_fixtures`. Instead I defined the reader method
manually and it checks `use_transactional_fixtures`. If it was set then
it should be used, otherwise it should return the default, which is
`true`. If someone uses `use_transactional_tests=` then it will
overwrite the backwards-compatible method with whatever they set.

The testing of error messages have been implemented wrongly a few times.
This is an attempt to fix it.

For example, some of these test should have failed with the new code.
The reason they are not failling with the new string is the fact they
were not being tested beforehand.

Also removed some cruft in the `setup` and `teardown` methods.

"active_support/testing/stream" is already required in `test_case.rb`.
Furthermore the test "test/cases/migration_test.rb" could no longer be executed
directly.

The same is not true of `define_attribute`, which is meant to be the low
level no-magic API that sits underneath. The differences between the two
APIs are:

- `attribute`
  - Lazy (the attribute will be defined after the schema has loaded)
  - Allows either a type object or a symbol
- `define_attribute`
  - Runs immediately (might get trampled by schema loading)
  - Requires a type object

This was the last blocker in terms of public interface requirements
originally discussed for this feature back in May. All the
implementation blockers have been cleared, so this feature is probably
ready for release (pending one more look-over by me).

It's finally finished!!!!!!! The reason the Attributes API was kept
private in 4.2 was due to some publicly visible implementation details.
It was previously implemented by overloading `columns` and
`columns_hash`, to make them return column objects which were modified
with the attribute information.

This meant that those methods LIED! We didn't change the database
schema. We changed the attribute information on the class. That is
wrong! It should be the other way around, where schema loading just
calls the attributes API for you. And now it does!

Yes, this means that there is nothing that happens in automatic schema
loading that you couldn't manually do yourself. (There's still some
funky cases where we hit the connection adapter that I need to handle,
before we can turn off automatic schema detection entirely.)

There were a few weird test failures caused by this that had to be
fixed. The main source came from the fact that the attribute methods are
now defined in terms of `attribute_names`, which has a clause like
`return [] unless table_exists?`. I don't *think* this is an issue,
since the only place this caused failures were in a fake adapter which
didn't override `table_exists?`.

Additionally, there were a few cases where tests were failing because a
migration was run, but the model was not reloaded. I'm not sure why
these started failing from this change, I might need to clear an
additional cache in `reload_schema_from_cache`. Again, since this is not
normal usage, and it's expected that `reset_column_information` will be
called after the table is modified, I don't think it's a problem.

Still, test failures that were unrelated to the change are worrying, and
I need to dig into them further.

Finally, I spent a lot of time debugging issues with the mutex used in
`define_attribute_methods`. I think we can just remove that method
entirely, and define the attribute methods *manually* in the call to
`define_attribute`, which would simplify the code *tremendously*.

Ok. now to make this damn thing public, and work on moving it up to
Active Model.

- Added include for the same in ActiveSupport::Test.
- Removed occurrences of silence_stream being used elsewhere.
- Reordered activesupport testcase requires alphabetically.

- Removed require of silence stream from test_case

- Moved quietly method to stream helper

- Moved capture output to stream helper module and setup requires for the same elsewhere

`silence_stderr`, `silence_stream`, `capture` and `quietly`.

`Computer` class needs to be require

See #17217 for more details

Fixes #17170

Sufficiently large integers cause `find` and `find_by` to raise
`StatementInvalid` instead of `RecordNotFound` or just returning `nil`.
Given that we can't cast to `nil` for `Integer` like we would with junk
data for other types, we raise a `RangeError` instead, and rescue in
places where it would be highly unexpected to get an exception from
casting.

Fixes #17380

This method would assume that if last migration in the migrations
directory matched the current schema version, that the database was up
to date, but this does not account for new migrations with older
timestamps that may be pending.

As per discussion, this changes the model generators to specify
`null: false` for timestamp columns. A warning is now emitted if
`timestamps` is called without a `null` option specified, so we can
safely change the behavior when no option is specified in Rails 5.

The fixtures are still in play, adding a new column without a default and `null: true`
is not possible. This reverts back to leaking global state, as our `schema.rb` adds
the `null: false` constraint on this field.

A future solution would be to make the `migration_test.rb` run independent of fixture tables.
This way we can simply drop the state after test execution, without worrying about side effects.

/cc @zuhao

If we want to have type decorators mess with the attribute, but not the
column, we need to stop type casting on the column. Where possible, we
changed the tests to test the value of `column_defaults`, which is
public API. `Column#default` is not.

For consistency with https://github.com/rails/rails/pull/15557

Missed a case that only occured for mysql/mysql2

With ActiveRecord::Properties, we now have a reasonable path for users
to continue to keep this behavior if they want it. This is an edge case
that has added a lot of complexity to the code base.

Follow-Up to https://github.com/rails/rails/pull/14348

Ensure that SQLCounter.clear_log is called after each test.

This is a step to prevent side effects when running tests. This will allow us to run them in random order.