To reproduce the issue:

- Enable Avatax in Accounting settings
- Go to the 'All' product category and set Avatax Category '[D0000000] Digital goods'
- Create a subscription order and set Deco Addict as the customer (is exempt)
- Set the Avatax fiscal position
- Confirm the order
- Preview in portal view
- Notice the tax is not equal

The subscription portal view was changed in #49963 to only display lines to be invoiced. So non-recurring lines were no longer shown. Because of this, the regular `tax_totals` field cannot be used in the portal anymore. Tax totals need to be recomputed for just those lines. This was done in a new method: `_next_billing_details()`.

This method recomputes tax totals using account.tax records, which won't be correct in many cases when using an external tax calculator. The percentage field that we set on the tax is only informational, and won't take exemptions into account.

Up to this point, the issue was only cosmetic. The customer was still charged the correct amount. This changed in #72120. Instead of charging `amount_to_invoice`, it now charges the amount calculated by `_next_billing_details()`. This, as stated above, won't always be correct.

To resolve the problem we first override `_next_billing_details()` so that it returns `tax_totals` based on line amounts. Those fields are the authoritative amounts that we set during external tax calculation [1]. This solves the cosmetic issue described above in most cases. However, the wrong totals are still displayed right after paying a subscription. This happens because the payment changes the state of the subscription, which invalidates the line amounts and recomputes them from `account.tax` again. We already overrode the `/my/subscriptions` controller to insert an external calculation and avoid this, but it happened after `super()` which is too late. At that point `_next_billing_details()` is already evaluated, with the incorrect values already in `qcontext`. To solve that we move the call before `super()`.

We also change `next_amount_invoice` to be the sum of invoicable lines, again basing this total on the authoritative amounts returned by the external tax calculator. We cannot use `amount_to_invoice` like before, because that breaks the "Anticipate payment" feature which was fixed in #72120. This solves the issue of charging the wrong amount.

opw-4315535
opw-4363065

[1] https://github.com/odoo/enterprise/blob/84aa5e2fb064bc0366e952cbd4eaf3628ea24b73/sale_external_tax/models/sale_order.py#L43-L55

PR note: built on top of #73921