Collections can take advantage of `multi_read` if they render one template
and their partials begin with a cache call.

The cache call must correspond to either what the collections elements are
rendered as, or match the inferred name of the partial.

So with a notifications/_notification.html.erb template like:

```ruby
<% cache notification %>
  <%# ... %>
<% end %>
```

A collection would be able to use `multi_read` if rendered like:

```ruby
<%= render @notifications %>
<%= render partial: 'notifications/notification', collection: @notifications, as: :notification %>
```

Makes caching a collection of template partials faster using `read_multi`
on the Rails cache store.

Some caching implementations have optimized `read_multi` so we don't have
to check in the cache store for every template.

fix syntax error in render partial example [ci skip]

Updating Query Tracer github repository

...so it doesn't look like you *have* to use SQL strings for that case (not
anymore!). Would like to replace the SQL string example with something that
you cannot do with the "normal" query API, but I could not come up with a
short, realistic example. Suggestions welcome!

Using enum names in SQL strings doesn't actually work, the test was wrong (fixed
in 3dfd1bab).

Make sure we have coverage for both the find/build cases

The previous edit kind of de-emphasized that, so changing it to be more explict.
(It also avoids showing it as if it's a string-keyed hash.)

Also updated the documentation about the new ability to query them normally,
and added test to make sure they work!

Allow symbol as values for `tokenizer` of `LengthValidator`

Correct module name in deprecation message.

Improve deprecation warning message

`has_secure_token` hasen't been released yet. No need to track
every change in the CHANGELOG.

Do not overwrite secret token value when already present.

[ci skip] escape under score

require rack/utils in exception_wrapper

```
user = User.create(token: "custom-secure-token")
user.token # => "custom-secure-token"
```

there's really no benefit here.  It's the same number of lines without
the meta programming and is faster

now we don't have to call reset! everywhere

We shouldn't cache if it's not absolutely necessary. Removes
route caching and instead skips using the `url_helpers` is the
integration test session doesn't require it. Benchmark ips on
integration and controller index method tests below.

Without any caching or changes to `#url_helpers`:
```
Calculating -------------------------------------
INDEX: Integration Test
                        71.000  i/100ms
INDEX: Functional Test
                        99.000  i/100ms
-------------------------------------------------
INDEX: Integration Test
                        728.878  (± 8.0%) i/s -      3.692k
INDEX: Functional Test
                          1.015k (± 6.7%) i/s -      5.148k

Comparison:
INDEX: Functional Test:     1015.4 i/s
INDEX: Integration Test:      728.9 i/s - 1.39x slower
```

With caching on `#url_helpers`:
```
Calculating -------------------------------------
INDEX: Integration Test
                        74.000  i/100ms
INDEX: Functional Test
                        99.000  i/100ms
-------------------------------------------------
INDEX: Integration Test
                        752.377  (± 6.9%) i/s -      3.774k
INDEX: Functional Test
                          1.021k (± 6.7%) i/s -      5.148k

Comparison:
INDEX: Functional Test:     1021.1 i/s
INDEX: Integration Test:      752.4 i/s - 1.36x slower
```

Afer removing the caching and bypassing the `url_helpers` when not
necessary in the session:
```
Calculating -------------------------------------
INDEX: Integration Test
                        87.000  i/100ms
INDEX: Functional Test
                        97.000  i/100ms
-------------------------------------------------
INDEX: Integration Test
                        828.433  (± 6.4%) i/s -      4.176k
INDEX: Functional Test
                        926.763  (± 7.2%) i/s -      4.656k

Comparison:
INDEX: Functional Test:      926.8 i/s
INDEX: Integration Test:      828.4 i/s - 1.12x slower
```

Extract `DateTimePrecisionTest`

Use SQL COUNT and LIMIT 1 queries for none? and one? methods if no block or limit is given,
instead of loading the entire collection to memory. The any? and many? methods already
follow this behavior.

[Eugene Gilburg & Rafael Mendonça França]

The datetime precision tests for any adapters is duplicated.

Add tip for skipping `partial` and `locals` options for `render`

ActionController#translate supports symbols

Allow `:precision` option for time type columns

remove unnecessary assignment/parameter passing in AS::Callbacks...::Around (master branch)