Use a metaclass for config's singletons

[mikeshardmind]

Type

• Bugfix
• Enhancement
• New feature

Description of the changes

This is technically a fix. This closes #3136

#3136 isn't what we had in mind when handling config as a singleton (and we don't intend for people to think accessing other cog's data should be done without that cog being designed for it), but we should be preventing reinitialization of existing config objects from this.

This also removes the potential for an error to be raised in a safe case of using init_group multiple times in the same config object, allowing multiple cogs to more safely share a config object if related.

It will still error if you try to change the identifier count of a group as this would be unsafe.

[mikeshardmind]

This one shouldn't be merged without @tekulvw signing off on it. It's not a release blocker, and will be moved out of the 3.2 milestone should it not be ready in time.

[TrustyJAID]

This fixes an issue I had when using get_conf multiple times within my own cog.

[mikeshardmind]

RIP, wrong branch...

[mikeshardmind]

It's been a few months waiting for a potential yes/no out of respect for the initial long discussion in discord about this not using a metaclass.

As this fixes an issue people are currently experiencing and there has been no response, I'm unwilling to hold this longer.

[mikeshardmind]

This needs an additional modification beyond this prior to merge, will handle tommorow.

[mikeshardmind]

The other potential failure related to shared config access is patched now too.

With these changes, it's still unsafe to interact with config objects you don't fully control for both practical purposes and synchronization reasons, but config objects can be safely shared if the various sync concerns related to this are handled.

[jack1142]

LGTM