### Batch of fixes coming from 16.0 and 16.3

- Stop relying on translated attributes from discuss components for Knowledge
  macros selectors and use classes instead.
- Prevent registering fields for Knowledge macro from Form views inside a dialog
  (modal).
- Use the notebook page `name` attribute instead of `string` to switch tabs in a
  Form view, since the `string` is translated. After this fix, an html_field in
  an unnamed notebook page won't be considered for Knowledge macros and the
  buttons won't appear.
- Don't allow macros to click multiple times on the same element during a
  trigger step. This could be an issue if the macro steps advance faster than
  the time it takes for a component to re-render after it's state changed
  because of the click (i.e. for a toggle, the macro could toggle again and
  return to the original state, resulting in the rendering being aborted).
- Ensure that the macro "use as description" searches for an editable version of
  the `html_field` (if it finds a non-editable version, it should try and switch
  to a notebook tab to find the editable version).
- Fix a semantic typo in Knowledge service (`xmlDoc` property was misnamed
  `fieldInfo`).
- Remove unnecessary unregistration of the current commandsRecordInfo (the
  explanation in the comment is wrong as controllers get an unique `jsId` for
  each instance, even for the same controller concern the same view called later
  in the breadcrumbs sequence.
- Don't register html fields for a Knowledge macro if their form view is in
  readonly mode or equivalent (non-editable).
- Remove usage of `interval` macro property as it is obsolete since [1].
  It is replaced by `{ defaultCheckDelay: 16 }` for the MacroEngine (16 ms
  between each step of a Macro).

[1]: https://github.com/odoo/odoo/commit/3a798039d6f200f8e28448ddb6a2d3c46654a203

### Macros refactoring (16.5+)

Keep only one form controller patch in Knowledge.

Refine the way the chatter and html form fields are detected for Knowledge
macros:
- Instead of updating the `commandsRecordInfo` at every patch if the record's id
  changed, it can be done as an `onWillUnMount` hook, since we only care about
  the last visited record of the form view.
- Use a `CallbackRecorder` to accurately ask the `Chatter` whether the current
  user is able to send messages or attach files, instead of relying only on the
  presence of the chatter in the `xmlDoc`.
- Add/Move some functions related to registering/discarding/validating a
  `commandsRecordInfo` in the `KnowledgeCommandsService` to limit the amount of
  functions added in the `FormController`.

Use action service to restore the form view instead of clicking on the
breadcrumbs in the DOM. Breadcrumbs are only checked to ensure that the
current view has a breadcrumbs history. This is more robust against future
designs of the breadcrumbs (where not every element of the breadcrumbs list is
displayed directly as a link (some of them can be hidden in a popper).

Add comments to better explain the macro processes and the
`KnowledgeCommandsService`.

Add a timeout of 10 seconds for macros, to give back control to the user if a
macro is stalled.

Knowledge macros rely on the name attribute of a notebook page to switch
between tabs in a Form notebook. That attribute is not mandatory, so some views
with a valid html_field did not have one. This commit add the name attribute
so those fields can now be manipulated by Knowledge macros.

See `searchInXmlDocNotebookTab` in `abstract_macro.js` for more details about
the usage of the `name` attribute in Knowledge macros.


task-3410128

Forward-Port-Of: odoo/enterprise#45672
Forward-Port-Of: odoo/enterprise#45128