When changing the destination location of a picking, the destination
location of the stock moves are not updated and the user may not
even notice it.

To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Inventory > Operations > Receipt, New
   - Add an operation
   - Change the destination location of the picking
3. Save
4. Mark as Todo
5. Open the created move

Error: the destination location of the stock move is still the
initial one

On the picking model, there are two fields that contain the stock moves:
https://github.com/odoo/odoo/blob/17a63a6cda41a44e3d4ff8b5a9042e93ba956bc8/addons/stock/models/stock_picking.py#L612-L614
Where `move_ids_without_packages` is a subset of `move_ids`

When editing the operations of a picking, we are actually dealing
with the field `move_ids_without_packages`. So, when changing the
destination location of the picking, the webclient sends the SMs via
the field `move_ids_without_packages`, i.e.: the web client does not
provide any value for `move_ids`.

Server side, when creating a `new` record based on the provided
values, we will handle the inverse of `move_ids_without_packages`,
i.e.: we will make sure that the stock moves have the field
`picking_id` correctly defined:
https://github.com/odoo/odoo/blob/a4c2f66700dd98487ac6bb8f0f25fdc4abffd0bf/odoo/models.py#L6366-L6374
**But** we don't define any value for the siblings of the field. It
means that we don't set any value for the field `move_ids`.

This will lead to the bug: later on in the onchange, we flag all
fields that will have to be recomputed:
https://github.com/odoo/odoo/blob/b794f0f332f473deb2c04eba60baf4761db3b508/addons/web/models/models.py#L983
And here we would hope that the field `location_dest_id` of the
stock moves will be flagged, as mentioned in the dependencies:
https://github.com/odoo/odoo/blob/68ae97bd27fbdc874922e03f52f8b0c7953df801/addons/stock/models/stock_move.py#L206-L207
But... In `_modified_triggers`, at some point, we are here
https://github.com/odoo/odoo/blob/a4c2f66700dd98487ac6bb8f0f25fdc4abffd0bf/odoo/models.py#L7200-L7203
Where `field` is `stock.move.picking_id`. So, we iterate on the
inverse field of `field`, i.e.: `move_ids` and
`move_ids_without_packages`. However, as explicitly mentioned in the
comment, we "use an inverse of field without domain", i.e.:
`move_ids`. We therefore read the value of this field on the picking
which is, because of the bug explained in the previous paragraph, an
empty record. As a result, the ORM considers that it does not have
to recompute any `location_dest_id`.

The ORM team is aware of the issue. They have tried to write a generic
solution (cf PR [191318](https://github.com/odoo/odoo/pull/191318)) but it led to a lot of other errors. So, the
issue has been considered as a limitation and added to a todo list
on their side.

In the meantime, it is possible to patch the issue with a
stock-specific fix.

Note: the issue will also happen when editing an existing picking.
Suppose a picking with one move SM01. The user adds a second move
SM02, does not save and edits the destination location of the
picking: for the same reasons, the ORM will only see SM01 and,
therefore, will call the compute method for SM01 only.

OPW-4379509

Versions
--------
- 18.0+

Steps
-----
1. Create a promotion to apply a fixed discount to an order;
2. create a promotion to apply a fixed discount to a specific product;
3. create a order with a taxed product eligible for the 2nd discount;
4. apply the first promotion;
5. apply the second promotion.

Issue
-----
Traceback:
> KeyError: account.tax(1,)

Cause
-----
Commit db12319e8b3b changed the way taxes get handled for discounts on the order total. They no longer automatically get a tax applied to them.

This causes a problem in the `_discountable_specific` method, which builds a `dict` using taxes of discount lines as keys to calculate discountable amounts.

Because the existing reward doesn't have a tax, this dict only has an `account.tax()` key, leading to a `KeyError` when trying to get discountable amount associated with the product-specific reward's taxes.

Solution
--------
Change the `dict` to a `defaultdict` which returns `0` for non-existing keys.

opw-4419764