With the abundance of tests we are accumulating, common test classes
have become the go to way to make test data readily available for all of
your module's tests and/or their dependent modules.

Unfortunately the cost of some of the `setUpClass` implementation has
also been rising as tests require more and more data.

As an example `AccountTestInvoicingCommon` which, with it's override of
`BaseCommon`'s `setUpClass` methods, is called 170 times during the
split from `account` to `auth_signup`.
With each call taking multiple seconds. This is a significant time loss
as (most of the time) the data generated is exactly the same from one
run to another.
(stats collected using `master-profile-setupclass-wbr` branch on runbot)

We realized the following:
 - We can run the whole test suite within a singular transaction without
   it being much more costly.
 - We could provide a way for common classes to define data that could
   be shared between test classes that share the same properties.

The changes only concern `odoo.tests.common.TransactionCase` and their
children.

### Transaction Strategy

Previously `TransactionCase`'s transactions would look like this:
(each box representing a transaction, with nested boxes being savepoints)
```
┌─ TestCaseA.setUpClass ─────────────────────────────────┐
│┌─ TestCaseA.setUp (test_foo) ─────────────────────────┐│
││  test_foo()                                          ││
│└──────────────────────────────────────────────────────┘│
│┌─ TestCaseA.setUp (test_bar) ─────────────────────────┐│
││  test_bar()                                          ││
│└──────────────────────────────────────────────────────┘│
└────────────────────────────────────────────────────────┘
┌─ TestCaseB.setUpClass ─────────────────────────────────┐
│┌─ TestCaseB.setUp (test_baz) ─────────────────────────┐│
││  test_baz()                                          ││
│└──────────────────────────────────────────────────────┘│
└────────────────────────────────────────────────────────┘
```

This will also be the case if no `setUpCommonData` is defined on your test class.

However, if `setUpCommonData` IS defined on your class, or a parent class, the
following plan will be executed instead:
Sample python code
```python
from odoo.tests.common import TransactionCase

class ModuleCommon(TransactionCase):
    @classmethod
    def setUpCommonData(cls):
        cls.data = cls.env['module.model'].create({'foo': 'bar'})

class ModuleTestA(ModuleCommon):
    def test_bar(self):
        self.assertEqual(self.data.foo, 'bar')

class ModuleTestB(ModuleCommon):
    def test_foo(self):
        self.data.foo = 'foo'
        self.assertEqual(self.data.foo, 'foo')

class ModuleCommonExtended(ModuleCommon):
    @classmethod
    def setUpCommonData(cls):
        cls.data_2 = cls.env['module.model'].create({'foo': 'baz'})

class ModuleTestC(ModuleCommonExtended):
    def test_baz(self):
        self.assertEqual(self.data.foo, 'bar')
        self.assertEqual(self.data_2.foo, 'baz')
```
```
┌─ ModuleCommon.setUpCommonData ───────────────────────────┐
│                                                          │
│┌─ ModuleTestA.setUpClass ───────────────────────────────┐│
││┌─ ModuleTestA.setUp (test_bar) ───────────────────────┐││
│││  test_bar()                                          │││
││└──────────────────────────────────────────────────────┘││
│└────────────────────────────────────────────────────────┘│
│                                                          │
│┌─ ModuleTestB.setUpClass ───────────────────────────────┐│
││┌─ ModuleTestB.setUp (test_foo) ───────────────────────┐││
│││  test_foo()                                          │││
││└──────────────────────────────────────────────────────┘││
│└────────────────────────────────────────────────────────┘│
│                                                          │
│┌─ ModuleCommonExtended.setUpCommonData ─────────────────┐│
││┌─ TestCaseC.setUpClass ───────────────────────────────┐││
│││┌─ TestCaseC.setUp (test_baz) ───────────────────────┐│││
││││  test_baz()                                        ││││
│││└────────────────────────────────────────────────────┘│││
││└──────────────────────────────────────────────────────┘││
│└────────────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────────┘
```

### Class selection and dependency strategy

One of our goals for `setUpCommonData` is that it could pretty much be a
drop-in replacement for `setUpClass`.
As indicated by the schema above however, it is not really compatible with our
new system, we want to be able to single out `setUpCommonData` for tests that
rely on that singular common class, which is why calling `super` is NOT allowed
within `setUpCommonData` (or at least calling `super().setUpCommonData`).
We take care of picking the class on which to call `setUpCommonData` and for
you, while the order is defined by the test class's `__mro__`.

Some common classes also provide methods that can be overwritten to change the
data generated by `setUpClass`, for which we provide the decorator
`odoo.tests.common.data_depends`.
`data_depends` takes a list of strings that are used as attributes to generate
a hash for our class; these can be regular attributes or methods (note that we
do not call the method, we simply store the reference to it).

The hash key for a class is defined as follows:
```python
tuple(
    tuple(
        Type[TransactionCase], # The class that defined `setUpCommonData`
        Tuple[Any], # The dependency data
        Type[TransactionCase], # The class that will be used to call `setUpCommonData`
    ),
    ...
)
```
The dependency data is built by iterating over the `__mro__` of said class and
adding each new definition for each attribute defined by `@data_depends`.

The class to install is the first class in the `__mro__` which has different
dependency data, with the added condition that it must be a subclass of the
previous installed class if there is one.

Consider the following:
```python
from odoo.tests.common import TransactionCase, data_depends

class ModuleCommon(TransactionCase):
    _name = 'foo'

    @data_depends('_name')
    @classmethod
    def setUpCommonData(cls):
        cls.data = cls.env['module.model'].create({'name': cls._name})

class ModuleTestA(ModuleCommon):
    def test_data_name(self):
        self.assertEqual(self.data.name, self._name)

class ModuleTestB(ModuleCommon):
    _name = 'bar'

    def test_data_name(self):
        self.assertEqual(self.data.name, self._name)

class ModuleTestC(ModuleCommon):
    _name = 'bar'

    def test_data_name(self):
        self.assertEqual(self.data.name, self._name)
```

Whilst all classes share the exact same `__mro__`, their dependencies differ.
This will of course cause a split as all test can not be ran within the same
transaction/savepoint.

```
┌─ ModuleCommon.setUpCommonData (_name = 'foo') ───────────────────────────────┐
│                                                                              │
│┌─ ModuleTestA.setUpClass ───────────────────────────────────────────────────┐│
││┌─ ModuleTestA.setUp (test_data_name) ─────────────────────────────────────┐││
│││  test_data_name()                                                        │││
││└──────────────────────────────────────────────────────────────────────────┘││
│└────────────────────────────────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────────────────────────────┘
┌─ ModuleCommon.setUpCommonData (_name = 'bar', install on ModuleTestB) ───────┐
│                                                                              │
│┌─ ModuleTestB.setUpClass ───────────────────────────────────────────────────┐│
││┌─ ModuleTestB.setUp (test_data_name) ─────────────────────────────────────┐││
│││  test_data_name()                                                        │││
││└──────────────────────────────────────────────────────────────────────────┘││
│└────────────────────────────────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────────────────────────────┘
┌─ ModuleCommon.setUpCommonData (_name = 'bar', install on ModuleTestC) ───────┐
│                                                                              │
│┌─ ModuleTestC.setUpClass ───────────────────────────────────────────────────┐│
││┌─ ModuleTestC.setUp (test_data_name) ─────────────────────────────────────┐││
│││  test_data_name()                                                        │││
││└──────────────────────────────────────────────────────────────────────────┘││
│└────────────────────────────────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────────────────────────────┘
```

The system takes care of organizing and ordering tests in a way to reuse data as
much as possible (according to the dependencies defined on the tests).
NOTE: While we do re-order tests we still follow `test_sequence` if defined.

#### Edge cases

A)
Consider the following:
```python
from odoo.tests.common import TransactionCase

class ModuleACommon(TransactionCase):
    @classmethod
    def setUpCommonData(cls):
        cls.module_a_data = cls.env['module_a.model'].create({'name': 'foo'})

class ModuleBCommon(TransactionCase):
    @classmethod
    def setUpCommonData(cls):
        cls.env = cls.env(context={'some_context': 'bar'}) # This could be creating+changing company
        cls.module_b_data = cls.env['module_b.model'].create({'name': 'bar'})

class ModuleCTestA(ModuleACommon, ModuleBCommon):
    def test_data(self):
        self.assertEqual(module_a_data.name, 'foo')

class ModuleCTestB(ModuleACommon, ModuleBCommon):
    def test_data(self):
        self.assertEqual(module_b_data.name, 'bar')
```

`ModuleCTestA` and `ModuleCTestB` actually share the same `__mro__` _AND_
dependencies.
In this case we can also note that `ModuleBCommon` will have an impact on
`ModuleACommon` due to changing the environment (according to `__mro__`).

This is the reason we include the install class in our hash key, the
dependencies would otherwise be the exact same between our test cases, but we
in fact need to know which class the data was installed upon to make sure the
data is available.

```
┌─ ModuleBCommon.setUpCommonData (install on ModuleCTestA) ───────┐
│┌─ ModuleACommon.setUpCommonData (install on ModuleCTestA) ─────┐│
││                                                               ││
││┌─ ModuleCTestA.setUpClass ───────────────────────────────────┐││
│││┌─ ModuleCTestA.setUp (test_data) ──────────────────────────┐│││
││││  test_data()                                              ││││
│││└───────────────────────────────────────────────────────────┘│││
││└─────────────────────────────────────────────────────────────┘││
│└───────────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────┘
┌─ ModuleBCommon.setUpCommonData (install on ModuleCTestB) ───────┐
│┌─ ModuleACommon.setUpCommonData (install on ModuleCTestB) ─────┐│
││                                                               ││
││┌─ ModuleCTestB.setUpClass ───────────────────────────────────┐││
│││┌─ ModuleCTestB.setUp (test_data) ──────────────────────────┐│││
││││  test_data()                                              ││││
│││└───────────────────────────────────────────────────────────┘│││
││└─────────────────────────────────────────────────────────────┘││
│└───────────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────┘
```

B)
Consider the following:
```python
from odoo.tests.common import TransactionCase

class ModuleCommon(TransactionCase):
    @classmethod
    def setUpCommonData(cls):
        cls.data = {
            'company': cls.env['res.company'].create({'name': 'test'})
        }

class ModuleTestA(ModuleCommon):
    test_sequence = 0
    def test_foo(self):
        self.data['company'] = self.env['res.company'].create({'name': 'test_2'})

class ModuleTestB(ModuleCommon):
    test_sequence = 1
    def test_bar(self):
        self.assertEqual(self.data['company'].name, 'test')
```

The above code will actually result in a cache error; the company referenced
within `cls.data` does not exist anymore.
It is also not possible to add a dependency on `setUpCommonData` as `data` does
not exist outside of running the tests.
It is not recommended to use dictionaries within `setUpCommonData` (or use
frozen ones) as they can not be rollbacked, one should stick to orm records.