Closes #8265

Since edd94cee, CollectionProxy
delegates all calculation methods - except count - to the scope,
which does basically what this method was doing, but since we're
delegating from the proxy, the association method was never called.

To perform a sum calculation over the array of elements, use to_a.sum(&block).

Please check the discussion in f9cb645d
for more context.

This reverts commit f9cb645d.

Conflicts:
	activerecord/CHANGELOG.md

Revert "Allow blocks for count with ActiveRecord::Relation. Document and test that sum allows blocks"

This reverts commit 9cc2bf69.

Conflicts:
	activerecord/lib/active_record/relation/calculations.rb

This improves memory and performance without having to use symbols which
present DoS problems. Thanks @headius and @tenderlove for the
suggestion.

This was originally committed in
f1765019, and then reverted in
d3494903 due to it causing problems in a
real application. This second attempt should solve that.

Benchmark
---------

require 'active_record'
require 'benchmark/ips'

ActiveRecord::Base.establish_connection(adapter: 'sqlite3', database: ':memory:')

class Post < ActiveRecord::Base
  connection.create_table :posts, force: true do |t|
    t.string :name
  end
end

post = Post.create name: 'omg'

Benchmark.ips do |r|
  r.report('Post.new')          { Post.new name: 'omg' }
  r.report('post.name')         { post.name }
  r.report('post.name=')        { post.name = 'omg' }
  r.report('Post.find(1).name') { Post.find(1).name }
end

Before
------

Calculating -------------------------------------
            Post.new      1419 i/100ms
           post.name      7538 i/100ms
          post.name=      3024 i/100ms
   Post.find(1).name       243 i/100ms
-------------------------------------------------
            Post.new    20637.6 (±12.7%) i/s -     102168 in   5.039578s
           post.name  1167897.7 (±18.2%) i/s -    5186144 in   4.983077s
          post.name=    64305.6 (±9.6%) i/s -     317520 in   4.998720s
   Post.find(1).name     2678.8 (±10.8%) i/s -      13365 in   5.051265s

After
-----

Calculating -------------------------------------
            Post.new      1431 i/100ms
           post.name      7790 i/100ms
          post.name=      3181 i/100ms
   Post.find(1).name       245 i/100ms
-------------------------------------------------
            Post.new    21308.8 (±12.2%) i/s -     105894 in   5.053879s
           post.name  1534103.8 (±2.1%) i/s -    7634200 in   4.979405s
          post.name=    67441.0 (±7.5%) i/s -     337186 in   5.037871s
   Post.find(1).name     2681.9 (±10.6%) i/s -      13475 in   5.084511s

If you accidentally pass a string and a symbol, this breaks. So
we coerce them both to strings.

Fixes #7715

If you want to change the STI type too, use AR::Base.becomes! instead

The `ActiveRecord::Fixtures::find_table_name` method was removed from "master" almost a year ago, but it was never deprecated.  Here it comes back, more dead than alive.

Closes #7551

Thanks @toretore.
https://github.com/rails/rails/commit/9e4c41c903e8e58721f2c41776a8c60ddba7a0a9#commitcomment-2134706

Two threads may be in method_missing at the same time. If so, they might
both try to define the same delegator method.

Such a situation probably wouldn't result in a particularly spectacular
bug as one method would probably just be overridden by an identical
method, but it could cause warnings to pop up. (It could be worse if
method definition is non-atomic in a particular implementation.)

(We will also need this mutex shortly anyway, see #8127.)

We should not need any `serialized_attributes` checks outside `ActiveRecord::AttributeMethods::Serialization` module.

Most apps upgrading from 3.x will have options for mass assigment in
their application.rb and environments/*.rb config files. Rather than
just raising a NoMethodError when copying the config, this commit
adds a warning message until either the protected_attributes gem
is installed or the relevant config options are removed.

These were removed with ActiveRecord::Model in
https://github.com/rails/rails/commit/9e4c41c903e8e58721f2c41776a8c60ddba7a0a9#L15L156

Rather than just changing it and hoping for the best.

Requested by @jeremy:

https://github.com/rails/rails/commit/ba1544d71628abff2777c9c514142d7e9a159111#commitcomment-2106059

So that the scope may be a NullRelation and return a result without
executing a query.

Fixes #7928

Fixes #8102.

I couldn't find a nicer way to deal with this than delegate the call to
 #scope, which will be a NullRelation when we want it to be.

This allows us to avoid hacks like the "return 0 if owner.new_record?"
in #count (which this commit removes).

Also, the relevant foreign key may actually be present even on a new
owner record, in which case we *don't* want a null relation. This logic
is encapsulated in the #null_scope? method.

We also need to make sure that the CollectionProxy is not 'infected'
with the NullRelation module, or else the methods from there will
override the definitions in CollectionProxy, leading to incorrect
results. Hence the nullify: false option to CollectionAssociation#scope.
(This feels a bit nasty but I can't think of a better way.)

For example, the following should not run any query on the database:

Post.new.comments.where(body: 'omg').to_a # => []

Fixes #5215.