Allow static asset serving from env variable (enhanced!)
Conflicts:
	railties/CHANGELOG.md

`db:schema:load` and `db:structure:load` do not purge the database

`rack.version` was bumped in https://github.com/rack/rack/commit/28e77c710ac2ddb35c436d78d72e28f28f964446

This reverts commit da5cc10e.

Fixes #18091

See also https://github.com/rails/rails/pull/18003#commitcomment-9030909

/cc @senny Is this change documented somewhere?

And also bundler cache

Add docs for AS::TestCase::test_order

Document `test_order` and `test_order=` from `ActiveSupport::TestCase`.

[ci skip]

Spelling fix [ci skip]

/cc @matthewd

Closes #17945

`db:test:prepare` still purges the database to always keep the test
database in a consistent state.

This patch introduces new problems with `db:schema:load`. Prior
to the introduction of foreign-keys, we could run this file against
a non-empty database. Since every `create_table` containted the
`force: true` option, this would recreate tables when loading the schema.

However with foreign-keys in place, `force: true` wont work anymore and
the task will crash.

/cc @schneems

Apparently PG does not validate against RFC 4122. The intent of the original
patch is just to protect against PG errors (which potentially breaks txns, etc)
because of bad user input, so we shouldn't try any harder than PG itself.

Closes #17931

[ci skip] Fix HTML format on comment

Fix name on changelog [ci skip]

Replace AS::TimeWithZone#since with alias to +

Use thread_safe gem version greater or equal to 0.3.4

The previous example was a little convoluted and the exposition
claifying the parts that were correct albeit not totally obvious
were interferring in my view.

This example has less things going on and gets to the key problem
with less balls in the air.

Remove unused line

[ci skip] Change three backticks to just one

fix link in autoloading guide [ci skip]

Stems from [Google group discussion](https://groups.google.com/forum/#!topic/rubyonrails-core/jSPbP-TNLb0).

Currently `AS::TimeWithZone` has two methods to add an interval to a time:
`+(other)` and `since(other)` ([docs](http://edgeapi.rubyonrails.org/classes/ActiveSupport/TimeWithZone.html)).

The two methods are "pretty much" equivalent in every case:

1. When adding any interval to an `AS::TimeWithZone` representing a `Time`:

  ```ruby
  t = Time.now.in_time_zone       #=> Thu, 04 Dec 2014 18:56:28 EST -05:00
  t + 1 == t.since(1)             #=> true
  t + 1.day == t.since(1.day)     #=> true
  t + 1.month == t.since(1.month) #=> true
  ```

2. When adding any interval to an `AS::TimeWithZone` representing a `Date`:

  ```ruby
  d = Date.today.in_time_zone     #=> Thu, 04 Dec 2014 00:00:00 EST -05:00
  d + 1 == d.since(1)             #=> true
  d + 1.day == d.since(1.day)     #=> true
  d + 1.month == d.since(1.month) #=> true
  ```

3. When adding any interval to an `AS::TimeWithZone` representing a `DateTime`:

  ```ruby
  dt = DateTime.now.in_time_zone    #=> Thu, 04 Dec 2014 18:57:28 EST -05:00
  dt + 1 == dt.since(1)             #=> true
  dt + 1.day == dt.since(1.day)     #=> true
  dt + 1.month == dt.since(1.month) #=> false
  ```

As you can see, the only case in which they differ is when the interval added
to a `DateTime` is in a format like `1.month`.

However, this usage of "since" is explicitly discouraged by the
[documentation of `DateTime#since`](https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/date_time/calculations.rb#L86L88):

> Returns a new DateTime representing the time a number of seconds since the instance time.
> Do not use this method in combination with x.months, use months_since instead!

And indeed, following this recommendation the correct result is returned:

```ruby
dt + 1.month == dt.months_since 1 #=> true
```

Therefore, my proposal is to remove the method definition of `TimeWithZone#since`
and instead replace it with a simple `alias_method :since, :+`.

The rationale is that the only case where they differ is a case that is
explicitly discouraged as "wrong".

In my opinion, having two methods named `since` and `+` and having to figure
out exactly what the difference is makes the codebase more confusing.

However, I understand this PR is "subjective", so if you feel like it's better
to ignore this, feel free to close the PR.

Thanks!

In the case of serialized columns, we would expect the unserialized
value as input, not the serialized value. The original issue which made
this distinction, #14163, introduced a bug. If you passed serialized
input to the method, it would double serialize when it was sent to the
database. You would see the wrong input upon reloading, or get an error
if you had a specific type on the serialized column.

To put it another way, `update_column` is a special case of
`update_all`, which would take `['a']` and not `['a'].to_yaml`, but you
would not pass data from `params` to it.

Fixes #18037

Add class level case operator support for error dispatching in Rescuable

Improving Method Chaining section [ci skip]

assert template should raise ArgumentError for unsupported layout types

"backoffice" -> "back office", "lookup" -> "look up" [ci skip]