Document and allow in RuboCop Current.organization in sidekiq workers

What does this MR do and why?

Document and allow in RuboCop Current.organization in sidekiq workers

This started at !216150 (comment 2949557775) where I first discovered that calling Current.organization in a Sidekiq worker led to a RuboCop error that linked to an issue that told me I couldn't use it. I then subsequently looked at our docs to figure out if this was a preference or whether it was technically not possible. The docs repeatedly said that it cannot be used in Sidekiq workers. After some more investigation I found !212406 (merged) which shows that it is indeed possible.

After this I considered the goal of the original rules and determined that expecting Current.organization to exist at the worker layer is similar to the controller layer. This is presumably why we added it to the middleware as well. For this reason I think it should be allowed in RuboCop as well as documented as OK.

The other practical reason to allow this is that adding arguments to Sidekiq workers is a breaking change that needs to be split over multiple releases. If we insist on adding the organization_id argument to many Sidekiq workers we may delay our Organization efforts or instead discourage teams from building new organization scoped features.

References

Screenshots or screen recordings

Before	After

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.