Add perform_all_later to Active Job Guide

[bhumi1102]

Overview

Add documentation related to perform_all_later for bulk enqueuing jobs.

Testing

Tested the new method in-app using sidekiq locally. Also tested documentation by running guides:generate, guides:validate and guides:lint locally.

[Ridhwana]

This looks great! ✨ I left a few suggestions and comments and marked them as optional etc.

[carlosantoniodasilva]

👍 looking good, just some minor bits of initial feedback.

[bhumi1102]

I've addressed all review feedback. Anything else before moving to PR on rail/rails? Oh, I'm up for moving the location of section 3.3, let me know if you have a strong preference to where?

[carlosantoniodasilva]

Looking great! I did another quick read through, and had another few minor suggestions, one typo in the multiple classes example.

I'm up for moving the location of section 3.3, let me know if you have a strong preference to where?

Not necessarily a strong preference, but there's a couple of reasons we might want to consider moving it to at least after the callbacks section:

• It has its own little section on callbacks, which links down the guide, and then there's a sub-section on callbacks with bulk enqueuing as well. Moving it down probably means we can merge the two into a single one.
• It explains the need to be backed by a backend queue, but we haven't gotten to the point of explaining what backend queues are yet. Moving it down would put it after that concept explanation.

I can also see why keep it early in the guide, within the section we explain about how to create and enqueue jobs. But it could be treated more as an "advanced" concept / form of enqueueing as well.

That doesn't need to stop you from moving the PR to rails/rails, maybe could even ask the broader community for feedback on that specifically if still unsure. We might still review the Active Job guide as a whole later on as well.

[bhumi1102]

I can also see why keep it early in the guide, within the section we explain about how to create and enqueue jobs. But it could be treated more as an "advanced" concept / form of enqueueing as well.

That doesn't need to stop you from moving the PR to rails/rails, maybe could even ask the broader community for feedback on that specifically if still unsure. We might still review the Active Job guide as a whole later on as well.

I moved the whole section 3.3 to a new top level section 8. And linked the new section within 3.3. Also cleaned up the 'callbacks' docs in multple places. Seems good for now. Going over the entire Active Job guide later on sounds good!

Will create a rails/rails PR now!