Fix issues for multiediting and updating for attribute form with more widgets pointing to the same field

[domi4484]

Fix #50197 Multiedit not working correctly when multiple widgets are available for the same field, and at the same time reduce the usage of signals/slots logic inside the attribute form.

In the attribute form there can be multiple widgets for the same field. But the dependency widget -> field was stored as a map with field as key. It means only the last added widget was stored in the map. The updating of the values was done with a signal/slot connection between valuesChanged() and setValues() of all widgets sharing the field.

I changed that using a multi map and thus storing all widgets pointing to a field in a variable. When a field value is changed the values of the same field widgets are set explicitly by looking in the map if thre are other to update.

This probably solves other unreported issues where in functions onConstraintStatusChanged and synchronizeState only the last added widget was updated.

[nyalldawson]

Merging this one should be deferred till after release -- touching this particular code introduces a nuclear level risk of regression 😱

[m-kuhn]

@domi4484 could you leave some notes about what was wrong and how this PR improves the situation?

[domi4484]

@m-kuhn yes I added some.

@nyalldawson i hope this will be a small step making this code more predictable. If this doesn't show any regression do you think it will be possible to backport it?

[3nids]

This is something we'd need to land in upcoming LTR.

I see two approaches:

• frozen for now, merge in next master 3.29 in, backport, in 3.28.1 or 2
• merge now for 3.28.0

I am not sure what is best. The sooner before it gets flagged as LTR sounds good, but just a bit of testing in master before might be worth (although it's not bullet-proof, especially just right after the release).

[andreasneumann]

I see two approaches:

* frozen for now, merge in next master 3.29 in, backport, in 3.28.1 or 2

* merge now for 3.28.0

If possible, I'd like to see this land in 3.28.x LTR. I'll be available to help testing. Both of Denis proposals would work for me - perhaps the sooner the better. People don't expect a .0 release to be production ready and it isn't yet labeled as LTR with 3.28.0

[nyalldawson]

@3nids

frozen for now, merge in next master 3.29 in, backport, in 3.28.1 or 2

This would be my vote. (Specifically backport for 3.28.1)

[3nids]

This would be my vote. (Specifically backport for 3.28.1)

I'm happy with this approach

[nirvn]

Code looks good to me -- could we add an additional test case that covers the scenario being fixed here? Other than that, +1 to merge.

[domi4484]

@nirvn thanks I have added one test for it

[nirvn]

Looks good to me, thanks for the test (I've ran it against master and it does fail, which is perfect :) ).