Reduce external gem dependencies: extract backup-fog into an internal plugin

[tomash]

Slightly different approach and therefore start from scratch after discussion in #1003

Mission: make backup modular for better maintainability. As shown, external gem dependencies can slow us down, including to a point where it's not possible to make backup compatible with Ruby 3+ as long as we have some of those dependencies.

Approach: move fog using code (S3 and Rackspace Cloud Files) into an accompanying plugin gem that will be maintained separately from the main backup gem.

Progress:

• First blood: removed fog dependencies into a separate gem. This already gives us Ruby 3.2(.2) compatibility.
• Removed rubocop, at least for now. Newer ruby versions mean newer rubocop, and newer rubocop means many renames, new cops and basically hundreds of offenses by current codebase.
• backup has green tests after extracting all fog-using code into backup-fog plugin and commenting-out its classes in autoload
• backup-fog has green tests and loads whichever classes it needs from main backup gem

[tomash]

Main gem specs are green.
backup-fog have quite a few failures and it seems I should either stick to older rspec-mocks version or fix them the hard way: rspec/rspec-mocks#1460

[tomash]

I think we're good! Of course there's some cleanup to do, but the main gem and backup-fog plugin both have green tests now.

[tombruijn]

I can't review this on a technical level anymore, not without doing lots of read up on the source code. If someone else can do a more in depth review, please :)

Not sure if I would want to merge it as-is to the main master branch. We could make a new 6.0 branch for you to work on, and merge that into main when it's done.

[tombruijn]

You can probably also remove some gems like hipchat, because I don't think that service is online anymore.

[tomash]

TIL that hipchat is no more 🕯️

[tomash]

I'll remove hipchat in a follow-up PR, for sake of clean separation.

[tomash]

Not sure if I would want to merge it as-is to the main master branch. We could make a new 6.0 branch for you to work on, and merge that into main when it's done.

6.0 branch sounds like a plan

[elthariel]

In addition to the few inline comments, I think we should discuss the namespacing/naming of things.

Shouldn't we do something like:

class Backup::PluginName::Storage::XXX ?

[elthariel]

Again, why dropping rubocop ? I don't remember if we discussed this 😅

[tomash]

#1003 here's why 😅

[tomash]

In addition to the few inline comments, I think we should discuss the namespacing/naming of things.

Shouldn't we do something like:

class Backup::PluginName::Storage::XXX ?

Moving plugins into a namespace on their own will enforce and underline the separation between "core" and plugins. I got a feeling from our previous conversations that we want to do the opposite, with keeping plugins in the same repo etc., so I haven't moved on with any new namespaces in code extracted to plugins.

I also see it as redundant, since class Backup::Storage::XXX will be provided only by plugin anyway, so there's no need to repeat plugin name in the module hierarchy.

[elthariel]

LGTM. Thanks !