Issue
-----
Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the one set up on the Fedex account, because the 'actualRateType' gets set to payor instead of preferred for the rate's 'rateType', which means

`d['rateType'] == rating_result['actualRateType']`

is false, so `actual` is empty, leading to an error when doing `actual['totalNetCharge']`.

Solution
-----
In the request we send, we hardcode

`'rateRequestType': ['PREFERRED']`

so we can look for a match using 'PREFERRED' as a prefix of `rateType`.

The Fedex API lists all possible values of the enum `rateType`

https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html

<details>
<summary>Enum values as per the API</summary>

"enum": [
	"INCENTIVE",
	"NEGOTIATED",
	"PAYOR_ACCOUNT_PACKAGE",
	"PAYOR_ACCOUNT_SHIPMENT",
	"PAYOR_CUSTOM_PACKAGE",
	"PAYOR_CUSTOM_SHIPMENT",
	"PAYOR_LIST_PACKAGE",
	"PAYOR_LIST_SHIPMENT",
	"PAYOR_RETAIL_PACKAGE",
	"PAYOR_RETAIL_SHIPMENT",
	"PREFERRED_ACCOUNT_PACKAGE",
	"PREFERRED_ACCOUNT_SHIPMENT",
	"PREFERRED_CUSTOM_PACKAGE",
	"PREFERRED_CUSTOM_SHIPMENT",
	"PREFERRED_INCENTIVE",
	"PREFERRED_LIST_PACKAGE",
	"PREFERRED_LIST_SHIPMENT",
	"PREFERRED_NEGOTIATED",
	"PREFERRED_RETAIL_PACKAGE",
	"PREFERRED_RETAIL_SHIPMENT",
	"RATED_ACCOUNT_PACKAGE",
	"RATED_ACCOUNT_SHIPMENT",
	"RATED_CUSTOM_PACKAGE",
	"RATED_CUSTOM_SHIPMENT",
	"RATED_LIST_PACKAGE",
	"RATED_LIST_SHIPMENT",
	"RATED_RETAIL_PACKAGE",
	"RATED_RETAIL_SHIPMENT",
	"UNKNOWN"
],

</details>

There are only 3 possible prefixes: `PAYOR`, `PREFERRED` & `RATED`, so replacing the other 2 by `PREFERRED` should be safe.

-----
Ticket:
opw-5482949

Forward-Port-Of: odoo/enterprise#105156

Steps to reproduce:
-------------------
1. Enable cash rounding, only for cash payment method
   - Rounding method doesn't matter, I tested with 0.05 nearest rounding
2. In PoS, make an order with the customer account, such that the total amount is not divisible by 0.05, i.e. when rounded, it's not the same amount. For instance, $5.27.
3. Close the session and reopen it, then select that customer, and click settle due
4. Select the Bank payment method, so a NON-Cash payment method.

Notice that the amount is being rounded, even though we have only enable rounding for cash methods. If we take my example of step 2, the amount became $5.25 instead of $5.27.

That is understandable when we settle with Cash, however, for Bank (non-cash), we should not round.

The fix
-------
Now when choosing a payment method to settle due, we also round the amount if needed, in `getTotalDueOfPartner`. Before, we always set the exact amount, regardless of the payment method and the rounding settings.

We now also apply rounding on the payment screen based on the selected payment method. Previously, the change was always rounded whenever rounding was enabled, ignoring whether rounding was restricted to cash methods. This behavior made sense for normal orders—where change is typically given in cash—but not when settling a due amount, since the customer can pay using any method. During due settlement, the change represents the amount the customer must pay, so rounding must follow the rules of the chosen payment method.

opw-5222985

Forward-Port-Of: odoo/enterprise#105234
Forward-Port-Of: odoo/enterprise#100278

### Steps to reproduce:

- In the settings enable: Multi-Steps route
- Create a product tracked by SN
- In the barcode app > Operations > Internal transfers > New
- Scan you tracked product
- Click on Validate > Invalid operation
- Scan a Serial number
#### > You can not click on validate anymore

### Cause of the issue:

The issue has been introduced in 41c6e7a90fd4f0cf84e74cf0ed036f4da0ec6112 in a try to avoid concurrency issue when calling the barcode validation too quickly. To be more precise, this commit added a `isValidating` property to the barcode model that is set prior to the rpc call and suppose to remove after in order tobypass subsequence calls of the `validate` method when a call is already in progress: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L477-L494 However, in the present case and since  orm call returns an error the the call the validate method is interupted at this orm call and the line
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L494 is not executed so that the this.Validating stays true and the button can not be clicked nor executed anymore:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L131-L133

### Fix:

We revert the incorrect fix: 42d77e751cb5e049ea1e81b44fca0d07e8f45b32 and we rather rely on the Mutex class of the JS framework just as done in the `_processBarcode`:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L505-L507 This will ensure that the validation calls will be processed sequentially and since the `button_validate` of stock pickings is ignored on done pickings because of the first soft fix https://github.com/odoo/odoo/pull/204790 :
https://github.com/odoo/odoo/blob/1664daf894ec878b64af8ab75c0d10f05e00df80/addons/stock/models/stock_picking.py#L1134-L1135
we have the guarantee that the records will not be validated twice.

opw-5388297

Forward-Port-Of: odoo/enterprise#104352
Forward-Port-Of: odoo/enterprise#103835