### Steps to reproduce issue:

1. Have Sales installed
2. Enable Analytic Accounting and create two Projects
3. Go into both Project Settings and add distinct Analytic Accounts
4. Create a Vendor Bill
5. Add a Product Line and put both accounts in the Analytic Distribution
6. Add an account in another column to one of the existing Analytic Distribution Lines
7. Go to Projects and open the Project Updates of the Project whose account was alone in the Analytic Distribution Line
8. You get the error:

>     invalid literal for int() with base 10: '[int],[int]'

### Explanation:

With commit odoo@dc696c8ed4850a83b6af721002a90f2944891923, the way IDs are stored changed. They are now computed in a csv string.
A part of the Analytic Accounting pipeline didn't get updated after that change, making a lot of the features not working properly.

### Suggested fix:

- We must take into account the multiple analytic plans in any order possible in the ID search.
- Because the amount of `account.move.line` can increase rapidly, the new ID search must be indexable.
- We reworked the counting query to avoid `account.move` being counted multiple times.

opw-3626619

when database uploaded without demo data and there is no any record in mrp production, and customer used load sample demo data, then it will create some demo record from this file which was actually defined in mrp/data/mrp_demo.xml with noupdate= True.

but as this xmlids has been created from python file using load samples it's noupdate='f' .
so without demo flag, we have `mrp.mrp_inventory_1` and `mrp.mrp_inventory_2` quant entry with noupdate='f'

so during upgrade as there was no demo file loaded, and this entry are with noupdate='f'
ORM try to remove those record quants record
in `_process_end` during upgrade from 17.0 to
saas-17.1, and which was create issues as
that quant contain some qty for storable product
so after upgrade as this qunts removed we have mismatched qty compare to before upgrade ( original database) so to fix that we need to pass noupdate='t'
and also need to fix in upgrade script with force_noupdate TRue.

```
Traceback (most recent call last):
  File "/tmp/tmpf_o_71pk/migrations/testing.py", line 207, in test_check
    self.check(value)
  File "/tmp/tmpf_o_71pk/migrations/stock/tests/test_on_hand_quantity.py", line 58, in check
    self.assertEqual(before_results, self.convert_check(after_results), self.message)
AssertionError: Lists differ: [[3, '1'], [4, '4'], [6, '2'], [7, '5'], [8[541 chars]36']] != [[6, '2'], [7, '5'], [8, '2'], [9, '1'], [1[521 chars]36']]

First differing element 0:
[3, '1']
[6, '2']
```

Previous fix: odoo/odoo#139013 added in the ability to handle a use case specific avoided due to its complexity and it being an edge case. I.e. the ability to do a Put in Pack in a batch picking where there is a shipping connector involved (i.e. when the `choose_delivery_package` wizard is opened).

Because the ability to handle this situation is now added to stable, we have to sort of support it now and handle it not breaking other flows. Here are the flows that need to be handled (and were broken by the previous PR): [In all cases, "Packages" setting needs to be activated and each picking needs at least 1 move of a consumable/storable product]

Flow 1: batch picking + put in pack for single picking
- Create 2 pickings of any operation type
- Create a new batch picking with these 2 pickings
- Open 1 of those pickings directly (i.e. not in the batch)
- Click on "Put in Pack"

Expected result:
Only the move from the open picking is put into a package

Result before this commit:
Both pickings have their moves put into the same package

Additional notes: Because this is not an obvious bug, users may already had this bug occur in their DBs without realizing it

===

Flow 2: batch picking (or multi-record calling of `action_put_in_pack`)
[different in v17 onwards due to removal of immediate_transfer boolean]
- Create 2 pickings (of different picking types)
- Select both pickings (through direct call in shell or rpc) and call
  `action_put_in_pack`

Expected result:
Moves are blocked from being put into same package since this situation
doesn't make sense (i.e. the products are moved to different locations
but the package can only be in 1 location)

Result before this commit:
The moves will all be put into the same package

Additional notes:
In theory batch picking creation has checks to avoid batches where
there are pickings with more than 1 picking type or have different
`show_reserved` values, but because `_package_move_lines` is a method
that can be called in different use cases (including multi-record
pickings) via customizations/future code changes, we add in checks to
prevent put in pack from finishing in those cases to avoid unexpected
behavior/stack traces. I.e. remember to respect existing
`self.ensure_one` checks since they're probably there for a reason.

===

Flow 3: batch picking w/pickings w/more than 1 delivery carriers (where none = a different carrier than having 1)
- Create 2 delivery pickings with different `carrier_id` values (i.e. different shipping methods assigned to them)
- Add both pickings to a batch
- Click "Put in Pack" in the batch picking

Expected result:
None, we should not handle this case because if the products are in the same package then the same package info will be sent to both carriers and the user will be double charged for every move (or charged(/potentially create the wrong shipping documents) when it shouldn't be in case of no carrier for one of the pickings)

Result before this commit:
All moves are put in the same package and the double charging/potentially incorrect shipping documents will occur

Additional notes:
This is the use case that was intended to be avoided when flow was originally decided to not be handled

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

Forward-Port-Of: odoo/odoo#157093
Forward-Port-Of: odoo/odoo#156068