**Current behavior:**
The `report.stock.quantity` view display incorrect quantities for products with stock moves which had their `quantity` field updated.

**Expected behavior:**
The report shouldn't add the delta quantity to data points prior to the updated stock move line date. 

**Steps to reproduce:**
Receive a different amount of product than expected after a purchase order:
- Create a purchase order for a product
- Receive higher quantity than expected by PO
- Look at the forecast view for that product
- Observe overestimated quantity in report_stock_quantity view prior to the delivery date

OR

Update quantity in a stock move line marked as 'done':
- Find a product with existing stock move lines
- Update quantity  of a stock move line with a bigger value
- Look at the forecast view for that product
- Observe overestimated quantity in report_stock_quantity view prior to stock move line date

**Cause of the issue:**
The `report_stock_quantity` view is dependent on `stock_move.product_qty` and `stock_quant.quantity`.
When quantities of stock move line related to a stock move are updated, the `stock_quant.quantity` field is also updated, while `stock_move.product_qty` is not from version 17 and up.
This difference cause erratic behaviour in the view.

**Fix:**
We could refactor the report_quantity_view and use the `stock_move.quantity` field instead of `stock_move.product_qty`, as the first one is computed as the sum of the stock move line quantities.

Task: [5003444](https://www.odoo.com/odoo/project/49/tasks/5003444)

The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs.

Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs.

[opw-5165200](https://www.odoo.com/odoo/project.task/5165200)

## Steps to reproduce:

[Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing)
1. Navigate to Apps and install l10n_mx_edi.
2. Switch to any of the Mexican companies that appear.
3. Navigate to Accounting > Configuration > Currencies.
4. Click into the USD currency.
5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field).
6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible.

[Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing)
1. Navigate to Accounting > Customers > Invoices.
2. Select New to create a new invoice.
3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES).
4. Add the 45 day Payment terms. This should change the payment policy to PPD.
5. Change the currency to USD.
6. Add the product FURN_8220 (or any with the unspsc_code_id set).
7. Set the unit price of the product to 58968.29.
8. Confirm the invoice.
9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again.
10. Select Register Payment, then Confirm Payment.
11. Select the Update Payments smart button.
12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line.

Message access is notably based on related document, given their
(model, res_id) pair. Model may customize the required access on
it in order to access their message. For example, you generally
need write access to create a message (post) but on some models
you can post when you can read. Calendar events message access depends
on calendar privacy settings.

This is controlled via '_get_mail_message_access'. However currently
it is "globally called", for all documents. It should be done on a
per-document basis, as each document could define different access
check.

Keep code somewhat optimized by doing access checks in batch for a
given operation.

Make _search and read symmetric. Reading documents should be allowed
on search results, and search results should match what is available
for reading.

Portal users have some specific domains applied when accessing
messages, see notably odoo/odoo@9cd9aaaa174ae1f2a0af12143a34eb4682ea6f59 (but also check for
'website_message_ids' domain, mail controllers, ...). However there
are still some cases where search and read are not coherent with
portal users. This is not really annoying as most messages are accessed
using sudo and correctly tailored domains via controllers but let
us try to have a more correct code.

Fix discuss display of chatter-related buttons
* not taking into account '_get_mail_message_access' to check if
  user has right to post (generally used to indicate users can
  post on readonly records, but not limited to that);
* not adding the same check on Activities button as on Send message
  and Log note. We consider generally that rights should be aligned
  and UX should match that behavior;
* not adding the same check on attachments buttons, currently limited
  to write access (or always accessible). This is a preliminary work
  for attachments, further fixes are probably incoming;

Mainly a backport of master improvement done at https://github.com/odoo/odoo/pull/214705 .

Task-5138368
opw-4785878