Description of the issue/feature this PR addresses:
As a result of the following commit 9a6b8fec280ccf63b14d3fdafdd39f534c54c646 normal users attempting to print invoices in SA company where the invocie has been ZATCA verified, are getting errors if they have insufficient access rights; for instance a normal user who has POS User access and Accounting/Billing is unable to generate PoS orders as they are forced to have the invoice checkbox set in the `l10n_sa_pos` and when the invoice is generated it is giving the following Traceback.

Current behavior before PR:
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/odoo/api.py", line 1013, in get
    cache_value = field_cache[record._ids[0]]
KeyError: 415613

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/odoo/src/odoo/odoo/fields.py", line 1161, in _get_
    value = env.cache.get(record, self)
  File "/home/odoo/src/odoo/odoo/api.py", line 1020, in get
    raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'account.edi.document(415613,).attachment_id'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/odoo/src/odoo/odoo/fields.py", line 1187, in _get_
    recs._fetch_field(self)
  File "/home/odoo/src/odoo/odoo/models.py", line 3230, in _fetch_field
    self.check_field_access_rights('read', [field.name])
  File "/home/odoo/src/odoo/odoo/models.py", line 2986, in check_field_access_rights
    raise AccessError(_(
odoo.exceptions.AccessError: The requested operation can not be completed due to security restrictions.

Document type: Electronic Document for an account.move (account.edi.document)
Operation: read
User: 40
Fields:
•⁠  ⁠attachment_id (allowed for groups 'Administration / Settings')
```


Desired behavior after PR is merged:
To Fix the issue and sudo() the access to the edi attachment



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

Forward-Port-Of: odoo/odoo#204912

**Problem:**
On a repair order, if the user is changed it changes the location (and recycled parts destination location) to the default one.
Additionally, when the order is confirmed, there is no way to change manually the location. The problematic use case is that if you first confirm the RO and then change the user, it will trigger a change of the location that you won't be able to revert manually.

**Steps to reproduce:**
- enable location in DB
- create a new repair order
- change the location and recycled parts destination location
- confirm the repair order
- change the responsible user

**Current Behavior:**
The location and recycled parts destination location fields values are changed to the default value for this operation type.

**Expected Behavior:**
The values of those fields shouldn't change after the repair order is confirmed.

**Cause of the issue:**
The _compute_picking_type_id depends on "user_id" and is therefore triggered when the user is changed
https://github.com/odoo/odoo/blob/1445d5adabf8eabe83e842c214655a74434bad4d/addons/repair/models/repair.py#L196
This triggers the _compute_location_id and _compute_recycle_location_id methods because they depend on
"picking_type_id"
https://github.com/odoo/odoo/blob/fa41c1d50f10ebab08437557ee863348a63de2c0/addons/repair/models/repair.py#L204
This happens regardless of whether the repair order has been confirmed.
Because the list of compute methods to be triggered when user_id is changed is computed all at once before
running them, adding an if statement at the beginning of _compute_picking_type_id (preventing the change
of value of picking_type_id if the state is not "draft") would not prevent _compute_location_id and
_compute_recycle_location_id to run.
Putting an if statement at the beginning of _compute_location_id and _compute_recycle_location_id
to prevent the change when the state is not in "draft" is not a good fix either. That's because
we wouldn't know if the computation is triggered by a change of user or a change of picking_type_id
(in which case we want the computation to run)

**Fix:**
I removed the 'user_id' dependency on _compute_picking_type_id


opw-4555293

Forward-Port-Of: odoo/odoo#202227

Partial backport of #202835

Nicer strategy for stable to avoid braking all existing clients tests

This should catch most case without introducing a lock and a mandatory allowance of the request.

- If the cookie is present, check if it is valid (request opening cursor in next test)
- Check if the test cursor was opened in the same test as the execute/rollback (request started in previous test executing in next)
- custom expected cookie for browser js to avoid allowing a request after wait_remaining_requests

All message could be silenced to kill the transaction without braking the test if it is a better strategy. 


Some design choices:
 - current_test is passed to Testcursor to avoid to add an import to odoo modules in sql_db, only impacts test logic. Parameter is optional. 
 - test cursor checks current_test before each operation (execute, commit, rollback). 
 - http_request_key is the test itself (between setup and cleanup), only exception is for browser js to avoid request executing during the end of the test (once browser is closed). It is the most common case.

Forward-Port-Of: odoo/odoo#205471
Forward-Port-Of: odoo/odoo#205190

When an image is added in a website page by using the `/image` command
of the Powerbox, it is not optimized like when the media dialog is
used to replace an image.
Also, when an image is replaced, the auto-optimization is not always
included in the last history step - which makes operations like
inserting a new paragraph remove the optimization.

This commit makes sure that the `image_changed` event is:
- triggered after the new image is inside the DOM
- completed before considering we are done
- included in the same history step that applied the media dialog's
  change.

It also avoids recomputing the auto-optimization several times for a
single trigger of the event.

Steps to reproduce:

Scenario 1:
- Drop a three columns snippet
- Put your cursor after "Feature 1"
- Press ENTER
- Use the "/image" Powerbox command to add an image that should be
resized by the auto-optimization

=> Image was the original uploaded image.

Scenario 2:
- Drop a three columns snippet
- Double click on an image
- Upload/select an image that will be resized by the auto-optimization
- Put your cursor after "Feature 1"
- Press ENTER

=> Image's optimization was lost because it happened after the history
step was completed.

task-4129429

Forward-Port-Of: odoo/odoo#205068
Forward-Port-Of: odoo/odoo#177433