Steps to reproduce:
- Open the VoIP softphone on a mobile device
- Enter a number
- Place the cursor in the middle of the number
- Tap on the *odoo* backspace button
=> The character before the cursor is removed but then the cursor jumps
   to the end of the input.

Note: this also happens when trying to add a number in the middle of
the typed number, using the softphone buttons, but this message focuses
the explanation on the backspace button.

Commit [1] introduced the bug while revamping VoIP and its keypad.
Before that commit, there was a simple `t-on-click` defined on that
backspace button. After the update, that `t-on-click` is still there but
alongside a weird `t-on-touchend.prevent="(ev) => ev.target.click()"`,
which is actually there to prevent zoom-in behavior on double-tap,
although, retesting it does not seem necessary (at least on Android).
In any case, this is the original cause of the bug.
Since [2], the keypad input is using the mail's `useSelection` hook,
which, among other things, manages what happens on click outside of the
input. Before [1], this happened when clicking on the backspace button:

1. The click is handled during its *capture* phase by the `useSelection`
   hook. It checks if clicked location should be considered, the answer
   is yes.

2. The next part of the handler is done in the next microtask (as the
   check is done asynchronously (?? that looks like a bad idea, but
   that's another issue)).

3. That "in the next microtask" part occurs before the event starts
   bubbling: the capture handler saves the cursor position as being at
   the end of the input (?? not sure why, but that's another issue).

4. The click is handled during its *bubbling* phase by the backspace
   button's `t-on-click`, which removes the character before the cursor,
   and sets the cursor position accordingly for the `useSelection` hook.
   The actual cursor position is untouched since [3] on mobile "because
   otherwise it would open the mobile keyboard", but there are other
   ways that would have prevented that I think... to confirm later for
   master via task-5366961 (this actually causes issues in HOOT tests
   but that's another issue).

5. The dialer/numpad component handles the input's focus/cursor. For
   that, it forces a focus and ask the `useSelection` hook to "restore
   the selection", which "restores" it to what step (4) asked.

After [1], this changed to:

1'. Same as step (1)

2'. Same as step (2)

3'. As the click was simulated instead of being the "natural" one
    triggered by the browser touchend handling, the `t-on-click` handler
    is called now, before the "in the next microtask" part of the
    capture handler is done. That means what step (4) did happens now.

4'. Now what step (3) did happens now.

5'. Same as step (5)... but since step (3) and (4) were basically
    swapped, the cursor is now restored as the way it was last saved:
    at the end of the input (again don't know why step the
    `useSelection` hook would want to save it like that though).

There are multiple solutions to fix this:
A. Remove the `t-on-touchend` handler, letting the browser do what it
   naturally does. Although, it might be needed to prevent the mentioned
   zoom behaviors on some phones?
B. Review why the `useSelection` hook wants to save the cursor at the
   end of the input on external click, the point is valid but I am not
   sure that should be this hook's job to enforce it.
C. Review why the `useSelection` hook wants to check if the click has to
   be considered asynchronously, there should be a better way.
D. Configure the `useSelection` hook to consider a click on the
   backspace button as to be ignored, as handled manually by its own
   handlers anyway.

Option (A) should probably be done, by confirming zoom behaviors can be
prevented another way, but it cannot be done in stable anyway. The (B)
and (C) options should be investigated but would also not be stable to
change; also that would modify an exposed hook's behavior so more risky.
Option (D) can probably be done either way and is targeted on fixing the
bug described only, so this is the solution this commit went for.
In master, option (A) will be investigated in the forward-ported version
of this fix.

However... the bug was actually solved 3 months after [1], at [4] thanks
to secret option (E): not removing the `t-on-touchend` but changing it
entirely to call the same handler as the `t-on-click` one. A bit more
stable than option (A) but still not stable.
However... that solution (E) was broken 1 month later, again, by commit
[5] which destroyed step (5) while fixing an unrelated bug. Without that
step, the input cursor is not repositioned after OWL changes the value,
and by default OWL places it back at the end.

The solution is to restore step (5): the problem was that we were
checking if the user was not typing in another input before re-focusing
the keypad input... but the code considered the keypad input itself as
"another input". This commit still adds solution (D) on top of fixing
that, for good measures.

Note that in 19.0+, there is at least another cursor-related bugs,
related to commit [6]. It will be fixed in the forward-port of this one
as they need each other's fix to both work. Really there should be
better ways to handle that cursor position in OWL... might be done in a
future refactoring.

This commit adds a test to hopefully keep the bug fixed, as inspired by
commit [7].

[1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd
[2]: https://github.com/odoo/enterprise/commit/2e8f18801156a8069e26fb3d61d4f8d84893e891
[3]: https://github.com/odoo/odoo/commit/adc5448adf863b99b9b2be29985e560f5c12dbd4
[4]: https://github.com/odoo/enterprise/commit/668467678312632b5b9ecf234280690151bf3078
[5]: https://github.com/odoo/enterprise/commit/db82135fd73d5077fc26be7206105192a845c2bc
[6]: https://github.com/odoo/enterprise/commit/a06c02e8e163ed052c1c4d25a56bea9b6409abde
[7]: https://github.com/odoo/enterprise/commit/613ef7332b0d21e947871e9d33b68d069f1412c2

Related to task-5366961

Forward-Port-Of: odoo/enterprise#101856

When adding a lot of loyalty programs with discounts to an order the updatePrograms method could be called multiple times in parallel, that would cause an issue where some of the programs were not applied correctly.

Steps to reproduce:
-------------------
* Create 7 loyalty programs that apply on the same product, each with a discount reward of 10%. (Give them different name)
* Create a POS order with 1 unit of that product.
> Observation: Only the 6 first programs are applied.

Why the fix:
------------
The issue is happening because the updatePrograms is called multiple times in parallel, and when coming to this block of code : https://github.com/odoo/odoo/blob/f3e74f9b840efef7c567ba31acd6ac61c79b5d6d/addons/pos_loyalty/static/src/overrides/models/pos_store.js#L182-L188 The last program has 2 coupons in the `couponPointChanges`, so it will proceed to delete all the coupons of the concerned program. To avoid this we use a mutex to ensure that only one call to updatePrograms is happening at a time.

opw-4974788

Forward-Port-Of: odoo/odoo#240639
Forward-Port-Of: odoo/odoo#239662