Commit 6a0028f91944b1d9e4eac026e86ca249ef5bc7ee introduced a change that
allowed field_triggers to be computed lazily per registry, this change
introduced a behavioral change that is not easy to notice, in order to
explain the behavioral change I will use the following example which was
the original bug reported:

* Install
* Create an app (create a new custom model M)
* Uninstall studio
* Uninstall fails because field display_name of the custom model M
   depends on field M.x_name which has been removed due to the
   uninstall process.

To understand why it didn't happen before the aforementioned commit, we
must first understand what happens with said commit applied:

* We trigger the uninstall of studio, this triggers the uninstall of
   any modules that depend on it, namely studio_customizations which is
   the module in which all customizations done with studio live in.

* We gather all data belonging to the studio_customization and we
   start deleting in the following order: ...,
   ir.model.fields.selection, ir.model.fields, ..., ir.model

* During the unlink process, we first remove the actual fields from
   the model instances before deleting their database reflections, this
   is done in the ir.model.fields._drop_column() method, it is this
   method that will delete the x_name field but **not** the
   display_name field, since it is a base field and not a custom one.

* After the deletion of the fields in memory, we call modified() to
   mark fields that might've depended on the fields we just modified so
   that they can be recomputed later.

* The call to modified will in turn access field_triggers, but since
   we're in a new registry and field_triggers is a lazy property, it
   will be computed right at this moment, this means that it will call
   resolve_depends on the display_name field which still exists, and
   this field has a dependency on the x_name field that we just
   deleted! This is what will trigger the crash.

With that context, we can now understand how it didn't crash before
commit 6a0028f91944b1d9e4eac026e86ca249ef5bc7ee:

* Before the aforementioned commit, the field_triggers attribute was
   computed during the registry's setup_models(), in the case of an
   uninstall this call to setup_models was done way before the
   uninstall step of the registry (Step 3 is the last to call
   setup_models before Step 5).

* This means that the old behavior was technically a bug, because
   right after removing x_name from the model, the field_triggers still
   contained a dependency from display_name to x_name, the former being
   no-longer present in memory.

With this commit, we simply reset the _rec_name and the dependencies of
the display_name if the x_name field is being removed, this ensures that
the computation of field_triggers won't crash and burn.

opw-2452498
opw-2478589

Forward-Port-Of: odoo/odoo#67747

The tour system is based on many assumptions, some of those not being
true all the time.  In practice, it works most of the time, but when
some slight changes occurs, we may observe undeterministic behavior.
This was actually the case in a dev branch working on assets: the order
of some files was changed, and it caused crashes in various tours.

This helped us identify two issues in the Tip class:

- the Tip class may be destroyed before it is completely started (so,
  the destroy method should not assume that the code in start was called
- the attach_to method should not resolve if the tip was destroyed
meanwhile.  This is critical, because some code uses that promise to act
on the widget.

This commit fixes both of these issues.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#67872

The 'addMockEnvironment' test utils allows to patch a lot of stuff,
including the session, for the sake of a test. However, it assumes
that it is only called once inside a test (or at least, that its
cleanUp function is always called before it is called again).

In this hr_attendance test, it isn't the case. 2 client actions are
instantiated, and addMockEnvironment is called for each of them,
in particular to patch the session.

The first call stores the current session (the real one), to restore
it in its cleanup (1). The second call stores the current session
(the mocked one, produced by the first call), to restore it in its
cleanup (2). The cleanup functions are called in order, so (1)
before (2), meaning that at the end, we end up with the session
being the mocked one of the first call to addMockEnvironment.

The very short term solution is to ensure, in this test, that the
cleanup functions are called in the correct order. For the long
term, we are working on a robust mechanism to correctly clean up
everything after a test.

Issue spotted in the assets revamp task, which mixed a bit the
order of the tests.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#67852