**Impacted versions:**
 
 - 17.0
 - 16.0

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

The addition of `request._post_init()` in #104573, introduced the possibility that `_request_stack.pop()` is not called after `_request_stack.push(...)` was called before. This would happen in the case if request._post_init() raised an Exception.

Even though with the standard `SessionStore` this is extremely unlikely to happen the possibility remains. In any case, one shouldn't set the expectation that `request._post_init()` isn't allowed to raise, therefore by moving the function call into the try block, it makes sure that `_request_stack.pop()` is called in the finally block.

**Current behavior before PR:**

If `request._post_init()` raises an Exception, `_request_stack` is left in a polluted state. This can cause issues during RPC-Calls, since during an RPC-Call, the request in `_request_stack` is borrowed with the expectation that `_request_stack` is empty.

This can cause issues further down the line for completely separate requests which may break here:
https://github.com/odoo/odoo/blob/4b6dea23a04d7b5317a94e75c8a670de82762276/odoo/addons/base/models/ir_qweb.py#L879

It breaks because, `request` will not be `None` (as would be expected due to borrowing) but `session` is not set on the `Request` object since that only happens if `_post_init()` succeeds. This results in the following error for completely unrelated requests going forward:

```
AttributeError: 'Request' object has no attribute 'session'
```

As a side-note, in our environment this happened likely due to using [camptocamp/odoo-cloud-platform/session_redis](https://github.com/camptocamp/odoo-cloud-platform/tree/16.0/session_redis). I did a write-up of the specific issue I ran into myself and reproduction steps here: https://gist.github.com/Jenjen1324/81d3547e5713ba253b67970bc8388147

I'm also not sure if there might be any security implications leaving a *partially* constructed object in this stack.

**Desired behavior after PR is merged:**

It is no longer possible to have a broken request hanging on in `_request_stack`, be it in stock Odoo or with customizations.


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

Forward-Port-Of: odoo/odoo#166524

**Current behavior:**
In a multi-company environment, say we have a reusable box which has been used by multiple companies. While the box actively contains some product of companyA, companyB is not permitted to view their own stock transfers.

**Expected behavior:**
The current status of a package should not affect the accessibility of a company's picking history.

**Steps to reproduce:**
1. Setup 2 companies, for both:
        Enable packages
        Enable stock warehouse locations
        Enable multi-step routes -> set their in/out routes to 3-step (pick, pack, ship)

2. Create a reusable box type package, don't assign it to either company

3. In CompanyA, create a delivery using the reusable package and complete it so the package is fully emptied and ready to be reused

4. Switch to CompanyB, create a picking (any kind) using the same reusable box -don't finish the transfer- then switch back to CompanyA

5. Try to view Inventory transfers -> AccessError

**Cause of the issue:**
The delivery module adds the `_compute_shipping_weight()` method which is called on-demand when we try to open the transfers tree view. We will eventually look at packages from the picking that used the reusable package (which now 'belongs' to another company) and raise the AccessError.

**Fix:**
Use sudo() to read package records in the iteration over picking records.

We are only reading from pickings which belong to the current company, which makes the access check for the package records redundant (and as we see here problematic).

opw-3813917

Forward-Port-Of: odoo/odoo#166575
Forward-Port-Of: odoo/odoo#164677