Impacted versions:
- 16.0+

## Instanciate Behavior components after a collaborative step

How to reproduce:
- Edit a collaborative html_field in a form view with 2 users (in 2 distinct
  windows simultaneously) (i.e. a task in Project, there should be at least 2
  tasks)
- Be sure to click on the field with both user_1 and user_2 so the collaboration
  starts
- Add one /article command block with user_1
- Click right of the received /article command block with user_2

Current behavior:
- Sometimes, the cursor appears inside the /article command block, while it
  should be contenteditable=false (like a button)

Issue:
- The issue is that the Article Behavior was not properly instanciated, thus the
  contentEditable=false attribute could not be set.

Fix:
- trigger a `refresh_behaviors` event when the editor is reset (`resetEditor`)

## Ignore locks from Behavior components rendering in wysiwyg `setValue`

How to reproduce:
- Edit an html_field in a form view (on a model with at least 2 accessible
  records). i.e. in Project with at least 2 tasks and edit a task.
- Add a lot of /article command blocks (i.e. 10)
- Switch back and forth to and from the next record in the form view (button "next")

Current behavior:
- Traceback (may or may not happen, asynchronous "randomness")

Issue:
- Knowledge Behavior have asynchronous rendering which happens with the
  mutationObserver of the editor disconnected (because mutations should not be
  registered). If the resetContent happens before the lock is lifted, then the
  mutations for the content reset would not be registered

Fix:
- allow the `setValue` method to remove locks coming from Behavior components,
  and restart the observer if there is no lock left.

Note:
- When the "oe-protected" feature is fully implemented, Knowledge behaviors
  won't have to disconnect the mutationObserver of the editor, and this fix will
  be reverted.

see odoo/odoo#113813

Task-3208896

Forward-Port-Of: odoo/enterprise#37589