When using a different uom for a receipt than the uom of the product, the forecast will not take it into account correctly.

Steps to reproduce:
-------------------
* Create a product AA and track it by Kg
* Create and confirm a receipts for 10 000g of AA
-> On the product AA forecast, the value from the past start a -9990.

Observation:
-------------
To load the forecast it will create a ReportStockQuantity, all the forecast operation will be done on the sql query:
https://github.com/odoo/odoo/blob/427d398880c381981e088f7001f855a10d1cd581/addons/stock/report/report_stock_quantity.py#L47
In this query it will calculate the quantity of product and it will reconstruct the history of the inventory.
For dates intervals before the move date it will use quantity (the actual quantity moved), for moves after it will use product_qty (the expected quantity to be moved):
https://github.com/odoo/odoo/blob/427d398880c381981e088f7001f855a10d1cd581/addons/stock/report/report_stock_quantity.py#L152-L160
Since it is reconstructing the history of the inventory, for the dates before the move happend, it remove the quantity from the inventory:
https://github.com/odoo/odoo/blob/427d398880c381981e088f7001f855a10d1cd581/addons/stock/report/report_stock_quantity.py#L161-L166
The issue is that quantity is not in the same uom as product_qty, product_qty is in the uom of the product and quantity of the stock move.

opw-6401941

Forward-Port-Of: odoo/odoo#278396

**Description of the issue/feature this PR addresses:**

When a batch recompute of `vies_valid` contains both a parent (commercial) partner and a child sharing the same VAT, and the child happens to be iterated before its parent, the child ends up with `vies_valid=False` instead of the parent's real, freshly-checked value.

**Current behavior before PR:**

`_compute_vies_valid` loops over `self` in whatever order the batch happens to have:

```python
for partner in self:
    ...
    if partner.parent_id and partner.parent_id.vies_vat_to_check == partner.vies_vat_to_check:
        partner.vies_valid = partner.parent_id.vies_valid
        continue
    status = partner._check_vies_iap()
    partner._update_vies_status(status)
```

`Field.compute_value()` removes the whole batch from the "to compute" queue *before* running this loop (it does so upfront, in case the method does not assign every record). So when the loop reaches a child and reads `partner.parent_id.vies_valid` to reuse it, that field is no longer marked "to compute" for the parent, and reading it just returns whatever is currently cached/stored — which, if the parent has not been processed yet in this same loop, is still the old/default value. The child copies that stale value and, being a stored field, keeps it forever: nothing re-triggers its computation afterwards.

Example:
```python
parent = env['res.partner'].create({'name': 'Parent Co'})
child = env['res.partner'].create({'name': 'Child Address', 'parent_id': parent.id})
child.vat = 'BE0477472701'   # queues the child's compute first
parent.vat = 'BE0477472701'  # queues the parent's compute second
child.vies_valid   # False, even though the VAT is valid
parent.vies_valid  # True
```

**Desired behavior after PR is merged:**

Every partner without a parent is always computed before any child that may reuse its value, regardless of the batch's original order — so the child correctly ends up with the parent's real `vies_valid`.

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

Forward-Port-Of: odoo/odoo#279927

Purpose
=======
Fix the event, slot and ticket availabilities computation to make sure
the correct availabilities are taken into account when registering to an event.
The availabilities should be computed based on the event/slot/ticket limitations and
should consider the current order existing event registrations.

Also making sure the registration flow is usable by dynamically updating the available seats
display and making sure to check the event/slot/ticket limitations before confirming the registration
to prevent any crash at payment step.

Specification
=============
- Previously the event registrations already validated during the current order are
taken into account but only in the ticket seats available display.
This is an issue as the event/slot maximum number of seats is not considered meaning
the user is misleaded and could book a ticket even though it'll exceed the
limitations.
=> Fixing the issue by dynamically updating the availabilities per slot-ticket, per slot and
per ticket depending on the already validated registrations for the current order.

- Previously the availability per slot was computed using a sum on the slot-ticket availabilities.
However the UI allows multiple slot-tickets selection, example 2 Standard tickets and 1 VIP ticket,
meaning the sum of each slot-ticket availabilities (here 3) could exceed the event/slot limitation
(i.e. max 2 attendee per slot). The slot availability should be the minimum of the two (here 2).
=> Reworking the computation of the slot availabilities to consider the event/slot limitation as well.

- Fix the ticket seats available display for non-multi slot events.
When the event seats are limited (seats_max > 0 and seats_limited=True)
but the ticket seats aren't limited (ticket.seats_max == 0),
the ticket available seats shouldn't be based on the ticket.seats_available field
(which is only relevant when the ticket seats are limited) but should be
based on the event available seats instead.
This issues doesn't happen for multi slots events as in this case the
'get_slot_tickets_availability_pos' python method is called returning the correct
ticket availabilities.

- Make sure to check if the user selected more tickets than the available event/slot seats.
It's not checked and crashes at payment step.
When confirming the event configurator popup, each ticket quantity is checked based
on their own limitations (ticket available seats). However the total number of
selected tickets could be limited by the event or the slot as well (event/slot available seats).
Adding a check to make sure the total number of tickets doesn't exceed the event/slot limitations.

- Make sure to display the correct number of seats available/the correct slot count on the product card.
Currently, the number of available seats for non-multi slots events on the product card isn't correctly computed.
When the event has limited seats and at least one unlimited ticket, the computation should use the event
available seats. Instead of that, it uses the sum of every ticket seats available even though this field is only
relevant when the tickets are limited.
Currently the slot count on the product card is the one of the future slots but some of those slots
could be unavailable (their button disabled on the slot selection popup) and shouldn't be included
in the product slot count.

- Do not raise error when trying to register to a multi-slots event without any ticket max seats
limitations.
Currently, if not a single ticket has an availability > 0, a danger notification is raised
preventing the registration to the event. However, the availability is not necessarily an integer,
it could be equal to "unlimited" and in this case the danger notification will appear even though
there are available tickets. Fixing the issue by evaluating "unlimited" tickets to be available.

- Dynamically adapt the number of tickets left depending on the ticket selection.
Currently, on the event configuration page, there's a counter with the number of tickets left
under each ticket name. This number is never updated no matter the selected tickets.
The only indicator to know if there's at least one ticket left is a color indicator.
The color indicator is not enough, if there is 5 tickets left, selecting 3 tickets will need
to update the counter accordingly to 2 so that the user knows what is happening.

Task-5079357

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