Recent changes and refactorings in the addresses management of the ecommerce checkout have restricted the ability of customers to use and update sibling/parent addresses in their own company.

Those changes have also increased the checks on addresses to make sure that the necessary information is available to ensure proper delivery and invoicing to the customer.

Nevertheless, some address, either from the past, or from other flows might still be incomplete, and be the default delivery/billing address of a given customer, despite belonging to siblings or to their parent company.

In those situations, the customer could be constantly requested to fill the incomplete address and be automatically redirected on the /shop/address page to fill the missing information, where he would face a Forbidden (403) error as they cannot update an address that doesn't belong to them.

This commit makes sure to consider a default address as complete if the current customer is unable to edit it.

opw-4202528

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

Steps:
- create a bom for Product A with the following component: Semifinished B, ratio 1.0
- create a bom for Semifinished B with the following component: Raw C, ratio 1.0
- add A with its bom, B should be created automatically after adding A
- add B (even if already present) with its bom, C should be created automatically after adding B
- input a forecasted demand of 1 for A (the period doesn't matter)
- there should be an indirect demand of 1 for B and C
- input a forecasted demand of 4 for B in the same period
- there should now be an indirect demand of 5 for C

Issue:
The indirect demand of C stays at 1 because the code bypasses the intermediate forecasted demand if there's an indirect demand from a level above

Fix:
Store the indirect demand at ratio in `subproduct_indirect_demand`
If `subproduct_indirect_demand` is different from `ratio * forecast_values['replenish_qty']`, substract it from the entire `replenish_qty` for the corresponding period when adding to `indirect_demand_qty`.

Cases:
`subproduct_indirect_demand` == `ratio * forecast_values['replenish_qty']`:
- base case, there's only indirect demand for B, skip
- there's forecasted demand on B and an equal reduction on the manual replenish qty, skip => the demand is reported to the next period as normal
- there's forecasted demand on B and a max to replenish qty that nullifies it, skip => same as above

`subproduct_indirect_demand` < `ratio * forecast_values['replenish_qty']`:
- base case, there's no indirect demand, proceed
- there's additional forecasted demand for B, proceed => add `(ratio * forecast_values['replenish_qty']) - subproduct_indirect_demand` to the `indirect_demand_qty` dict
- there's additional replenish qty for B, proceed => the additional qty is set on the first day of the period

`subproduct_indirect_demand` > `ratio * forecast_values['replenish_qty']`:
- there's a manually input `replenish_qty` that is inferior to the indirect demand, proceed => the parent_date is set at the end of the current period in case of lead time to prevent negative replenish qty on the period before

Steps to reproduce:
- Planning > Configuration > Employees > New
- Schedule > By resource > Filter for your employee
- Click on the employee's Gantt line and assign a shift
- Click the shift > Edit > Click the looping arrow next to date
- Your shift should now be recurring over the coming weeks
- Go to the 2nd week > Edit the shift's end date
- Check 'All shifts' at the top and save

There are 2 issues here:
1. A MissingError is raised
2. Even when bypassing that error, the planning is regenerating the slots from the original slot's start date to the 2nd slot's end date. (i.e. for a weekly recurrence you will now have 2 week long slots instead of the expected 1 week)

Both happen because when editing the start/end date of a recurring shift we simply unlink the existing ones and regenerate them from the original slot. Since they are unlinked we can no longer access the shift we were trying to edit (the 2nd occurrence) resulting in the MissingError. And because we regenerate from the first slot despite taking values from the second, we stretch the original slot, which is repercuted on every subsequently generated slot's dates.

opw-4154647