Metaclass class registry

[Karrenbelt]

trafficstars

Problem

The current use of metaclasses as a registry of classes is cumbersome at at best, and more often problematic. Currently we resort to the use of setup_class (sometimes setup) to copy (part of) the original state of the metaclass and teardown_class (sometimes teardown) in order to restore it. Regarding the current storage method:

• We should remove all behaviour_id, round_id, and similar such attributes, as they are redundant with respect to the class name.
• For payloads, we should not use transaction_type to store them.

Both of these lead to potential conflicts unnecessarily easily.

Solution

A solution to this problem could be to.

• Modify the hash map approach we now use to store them: we may store them by module and class name.
• Or my preferred solution: We may store them directly into a hash set. This requires our classes to be 1. hashable and 2. pickle-able (which should be the case). There should exist no circular dependencies and we can reference the respective classes directly where needed, instead of self-assigned ids.

The culprits:

https://github.com/valory-xyz/open-autonomy/blob/be508bade2c6565a9b4d204ff1ab15375e100660/packages/valory/skills/abstract_round_abci/base.py#L123-L178 https://github.com/valory-xyz/open-autonomy/blob/be508bade2c6565a9b4d204ff1ab15375e100660/packages/valory/skills/abstract_round_abci/base.py#L1678-L1693 https://github.com/valory-xyz/open-autonomy/blob/be508bade2c6565a9b4d204ff1ab15375e100660/packages/valory/skills/abstract_round_abci/behaviours.py#L44-L145

[DavidMinarsch]

See also https://github.com/valory-xyz/open-autonomy/issues/1779