PR #14052 Added a regression where it was only looking for methods in one
level up, So when the method was defined in a 2+ levels up the
inheritance chain, the method was not found as defined.

conflicting private method defined on its ancestors.

The problem is that `method_defined_within?(name, klass, superklass)`
only works correclty when `klass` and `superklass` are both `Class`es.

If both `klass` and `superklass` are both `Class`es, they share the
same inheritance chain, so if a method is defined on `klass` but not
`superklass`, this method must be introduced at some point between
`klass` and `superklass`.

This does not work when `superklass` is a `Module`. A `Module`'s
inheritance chain contains just itself. So if a method is defined on
`klass` but not on `superklass`, the method could still be defined
somewhere upstream, e.g. in `Object`.

This fix works by avoiding calling `method_defined_within?` with a
module while still fufilling the requirement (checking that the
method is defined withing `superclass` but not is not a generated
attribute method).

4d8ee288 is likely an attempted partial fix for this problem. This
unrolls that fix and properly check the `superclass` as intended.

Fixes #11569.

Fixing issue with activerecord serialization not being able to dump a record after loading it from YAML - fixes #13861

Similar to dangerous attribute methods, a scope name conflict is
dangerous if it conflicts with an existing class method defined within
`ActiveRecord::Base` but not its ancestors.

See also #13389.

*Godfrey Chan*, *Philippe Creux*

This was happening when a `super` call in an overwritten attribute method
was triggering a method_missing fallback, because attribute methods
haven't been generated yet.

  class Topic < ActiveRecord::Base
    def title
      # `super` would re-invoke this method if define_attribute_methods
      # hasn't been called yet resulting in double '!' appending
      super + '!'
    end
  end

TS::Cache#compute_if_absent guarantees that only a single thread will get to execute the provided block for a given key.

for attributes that are columns.

Object#respond_to? returns singletons and thus we inherit that contract.
The implementation of the predicate is good, but the test is only
checking boolean semantics, which in this case is not enough.

fixes #4208

If a query selects only a few columns and gives custom names to
those columns then respond_to? was returning true for the non
selected columns. However calling those non selected columns
raises exception.

    post = Post.select("'title' as post_title").first

In the above case when `post.body` is invoked then an exception is
raised since `body` attribute is not selected. Howevere `respond_to?`
did not behave correctly.

    pos.respond_to?(:body) #=> true

Reason was that Active Record calls `super` to pass the call to
Active Model and all the columns are defined on Active Model.

Fix is to actually check if the data returned from the db contains
the data for column in question.

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

This fixes the following behaviour:

    class Person < ActiveRecord::Base
      belongs_to :company
    end

    # Before:
    person = Person.select('id').first
    person[:name]       # => nil
    person.name         # => ActiveModel::MissingAttributeError: missing_attribute: name
    person[:company_id] # => nil
    person.company      # => nil

    # After:
    person = Person.select('id').first
    person[:name]       # => ActiveModel::MissingAttributeError: missing_attribute: name
    person.name         # => ActiveModel::MissingAttributeError: missing_attribute: name
    person[:company_id] # => ActiveModel::MissingAttributeError: missing_attribute: company_id
    person.company      # => ActiveModel::MissingAttributeError: missing_attribute: company_id

Fixes #5433.

In the end I think the pain of implementing this seamlessly was not
worth the gain provided.

The intention was that it would allow plain ruby objects that might not
live in your main application to be subclassed and have persistence
mixed in. But I've decided that the benefit of doing that is not worth
the amount of complexity that the implementation introduced.