Fix #first(limit) to take advantage of #loaded? records if available

[Empact]

I realized that first(2), etc. were unnecessarily querying for the
records when they were already preloaded. This was because
find_nth_with_limit can not know which @records to return because
it conflates the offset and index into a single variable, while
the @records only needs the index itself to select the proper
record.

Because find_nth and find_nth_with_limit are public methods, I
instead introduced a private method find_nth_with_limit_and_offset
which is called internally and handles the loaded? checking.

Once the offset argument is removed from find_nth,
find_nth_with_limit_and_offset can be collapsed into
find_nth_with_limit, with offset always equal to offset_index.

[rails-bot]

r? @chancancode

(@rails-bot has picked a reviewer for you, use r? to override)

[Empact]

@chancancode Thoughts on this?

[senny]

You could move this outside the assert_queries block. Then we don't have to do the actual code 2 times and we can assert that no queries are executed.

[senny]

r? @senny

@Empact I added a few minor comments. The change looks good.

[Empact]

@senny Made the changes you suggested - note test_loaded_first_with_limit was in the style of test_loaded_first, so I changed both.

2 questions:

• is it helpful to make a separate PR with the removal of the deprecated options, for future application?
• is there any guideline / thought on when things like this should be removed?

[senny]

@Empact It's not necessary to make a PR for the removal. Once we release a new Major or Minor version we go through all deprecations and remove the ones that are due. Usually they stay for one release cycle. Meaning that the option will be deprecated in 5.0 and will be removed from 5.1.

[senny]

@Empact thank you 💛

I've added a test-case to access more records than available to make sure it behaves the same as with a query. I also updated the 5.0 release notes to include the deprecation (0d2675f).

[Empact]

Thanks @senny! 🎆