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.

When inserting new records, only the fields which have been changed
from the defaults will actually be included in the INSERT statement.
The other fields will be populated by the database.

This is more efficient, and also means that it will be safe to
remove database columns without getting subsequent errors in running
app processes (so long as the code in those processes doesn't
contain any references to the removed column).

ActiveRecord#attributes optimization: minimize objects created