## Issue
When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead.

## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Product P
    - *Subscriptions* checked
    - *Invoicing Policy*: *Delivered quantities*
3. Create a Subscription S
    - Any Customer
    - Any plan
    - Product P (any quantity)
4. Confirm the subscription S, set the amount delivered to the quantity ordered, then create and confirm the invoice
5. On the subscription S, click *Upsell*, add the product P to the upsell, and repeat step 4 on the upsell
6. **The upsell's _Invoice Status_ is still _To Invoice_, even though we invoiced it in the previous step**

## Causes

In the `SaleOrderLine._compute_invoice_status`, the following condition skips line from orders that are not considered to be "subscriptions":

https://github.com/odoo/enterprise/blob/c33e668bbba37c34d18af8c5371ab80eedf1b965/sale_subscription/models/sale_order_line.py#L51-L62

This is the case of upsells, as explained here:

https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201

---

Updating the above condition to take upsells in account is not enough. The condition to set the `invoice_status` to `invoiced` does not work as expected either.

https://github.com/odoo/enterprise/blob/5f4bb0ca22d068247540a4dcae88905c7b312f3c/sale_subscription/models/sale_order_line.py#L77-L78

In fact, when invoicing the subscription/upsell manually, there are multiple cases where the `last_invoiced_date` will be after `today`, and the subscription will be invoiced, so its status should be `invoiced`.

| Upsell | Invoiced based on delivered quantities | last_invoiced_date      |
|--------|----------------------------------------|-------------------------|
| True   | True                                   | today + 1 month         |
| False  | True                                   | today                   |
| True   | False                                  | today + 1 month - 1 day |
| False  | False                                  | today + 1 month - 1 day |

An alternative logic is to consider the subscription to be invoiced as long as the `next_invoice_date` is not reached.

---

opw-5500585

Forward-Port-Of: odoo/enterprise#108614
Forward-Port-Of: odoo/enterprise#107967

**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions

**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)

if public_users_for_company:
    return public_users_for_company[0]
```

This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).

**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).

For now the fix archive the revoked portal user (keeping its previous non-public groups), to still be able to reactivate it later on, without mistaking it for the default public user of a company.

Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.

related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b

*Reapply the reverted fix properly to avoid template issues and blocking flows (https://github.com/odoo/odoo/pull/239477 and https://github.com/odoo/odoo/pull/236462)*

opw-4760550

Forward-Port-Of: odoo/odoo#250505
Forward-Port-Of: odoo/odoo#243056