Extract main processing logic from Geo::Scheduler::SchedulerWorker as another mixing or as a service class

Proposal

• the perform part of the code can probably be abstracted into a few other methods and/or into a block that yields control
• consider rethinking the structure, instead of requiring to implement multiple methods as a way to customize parameters, perhaps a service class that receives configuration params is a better fit
• if using mixing maybe it needs to be split into more than one as it has multiple responsibilities right now.

Reasoning

We are using inheritance as a way to reuse and share code, and this is leading us to many abstract/parent classes when we could probably isolate the "features" into mixins / concerns and just pick then at will.

By using mixins/concerns it can be easy to understand what a Worker class is doing (we can have very descriptive names), and it's easier to have slightly different classes reusing part of the code (inheritance works really well only when there is very little change from the proposed parent class, which is not our case).

Other issues / Links

see https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/7287#note_101269689