In a spreadsheet with multiple data sources (2 pivots), each data source initially loads and triggers a new evaluation upon loading. This results in two evaluations, even if both data sources resolve in less than 10ms apart. In such cases, the first re-evaluation becomes redundant, as a new one is immediately triggered.

The issue is worse when more than 6 RPCs are required, as most browsers limit network calls to 6 in parallel. Consequently, the 7th RPC will unnecessarily wait after the evaluation triggered by the first RPC to resolve.

For spreadsheets with many many data sources, the accumulation of these pointless evaluations significantly impacts performance. In a real-life scenario with 18 data sources from our production database, the spreadsheet took approximately ~33s to fully load and become reactive. With this commit, the loading time is reduced to ~7s (only one evaluation instead of 18).

Note that this testing was conducted locally, with minimal latency, and with a limited amount of data.

One consequence of this commit is that cells won't load incrementally as each data source loads. Instead, all cells will display "Loading..." until all data sources are loaded. Given the substantial speed improvement, we consider this trade-off worthwhile.


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

Forward-Port-Of: odoo/odoo#149767

## Description
Having several select menu containing a lot of options on a page may lead to significant wait times and browser crashes when selecting or deleting a value.

## Analysis
Sorting of the options is being computed on each mounted select menu during the useEffect() hook since this commit: https://github.com/odoo/odoo/commit/8a4485748f49c5b8fdb780b0bcd2435eeadd63b. 

### Before this commit
All of the select menu are sorted when the user select a value in one of them. This is not necessary as the sorting is already handled in beforeOpen.

### After this commit
Selecting or deleting a value from a select menu is significantly faster as the sorting is not being unnecessarily computed in useEffect() anymore.

## Benchmarks
When importing an Excel file containing 70 columns as an invoice with subfields search enabled, selecting/deleting an option from a select menu:
|             | Before  | After  |
|-------------|---------|--------|
| Selecting      | 31.2 s | 1.5 s |
| Deleting      | 35.9 s | 1.6 s |


## References
opw-3616438



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

Forward-Port-Of: odoo/odoo#146324

Steps:
- Install subscription app and razorpay provider.
- Configure and publish razorpay provider.
- Create a subscription and pay via razorpay.
 - Now change system date to next recurring date.

 Issue:
 - Subscription is in `Payment Failure` state even though payment is successfully captured.

 Cause:
 - Because of concurrent update in database while creating transaction from token for recurring charges
 - When razorpay make tokenize request via `_send_payment_request` method then transaction process data via `_handle_notification_data` and from web-hook so it tries to write on transaction with same data multiple times and at same time subscription also tries to write so because of concurrent update it skips to write on subscription and subscription stays in `Payment Failure` state.

 Fix:
 - Handle writing on subscription in there state changing method instead of trying to write in between when transaction processing so it does not skip writing on subscription and properly set/remove subscription state.

 task-3652228

Currently, a public user can't add any product to the cart when using GeoIP and Avatax.

### Steps to reproduce
* setup GeoIP[^1]
* setup Avatax credentials
* enable "Detect Automatically" on the "Automatic Tax Mapping (AvaTax)" fiscal position
* access to the website as a public user with an IP address from the US[^1]
* try adding a product to the cart.

You should be met with a validation pop.


[^1]: 
	This is quite annoying to reproduce on a local database. In cases like these, I find it much easier to directly modify the code in order to emulate the behavior we want. Here, you can simply replace the entire content of `odoo/addons/http_routing/geoipresolver.py` with the following: 	
	```py
	class GeoIPResolver(object):
	    @classmethod
	    def open(cls, fname):
	        return GeoIPResolver()
	    
	    def resolve(self, ip):
	        return {
	            'city': 'New York',
	            'country_code': 'US',
	            'country_name': 'United States',
	            'latitude': 40.7263,
	            'longitude': -73.9818,
	            'region': 'NY',
	            'time_zone': 'America/New_York'
	        }
	```

### Cause

For the Avatax fiscal position to work, we need the partner's country, state and zip code. Usually, this isn't a problem because the fiscal position is set after the Public User enters their address. But, when using GeoIp, the fiscal position is set right when the user lands on the page, based on their location data. This triggers a check for the address, but the Public User hasn't entered one yet, which causes a validation error.

opw-3625410

Forward-Port-Of: odoo/enterprise#53547