Checkbox labels are now one-time use for clicking to toggle their checkbox

[Keavon]

@TrueDoctor's PR #3337 introduced another regression (in addition to the ones reported in #3353 which @0HyperCube fixed in PR #3354) that I just found. It seems that most checkbox labels are now one-time use, meaning they can't be clicked after the first time to cause their checkbox to toggle. I presume this is because the random ID used to associate a label with a checkbox is being randomized and both widgets aren't being updated in unison.

Affected cases:

• File > New and click the "Infinite Canvas" label, which toggles once but can't be toggled again
• File > Export and click the "Transparency" label
• All the individual labels for checkboxes in the Overlays and Snapping menus:
  
• Switch to the Path tool, select a vector object's anchor point, and click the "Colinear Handles" checkbox label in the control bar

Cases which aren't affected:

• File > Preferences and click the "Zoom with Scroll", "Vello Renderer", and "Vector Meshes" checkboxes, these do work multiple times for some reason

[ashishmohapatra240]

hello @Keavon, can I work on this?

[Keavon]

Sure

[ashishmohapatra240]

Hello @Keavon, I am not able to reproduce the issue.

Issue.mp4

Isn't it the expected outcome? I tried toggling by clicking on the label and the checkbox in the "Infinite Canvas", "Transparency" and Overlay and Snapping menus. But not able to reproduce, Can you check if I am doing it right or not?

[Keavon]

You are testing in the last release, not master.

[ashishmohapatra240]

Got it! 👍

[TrueDoctor]

The current diffing system is pretty fragile. We either diff too much or too little, I think the main culprit for this is that the widget ids are chosen randomly. This was originally implemented before we had diffing because it allowed us to have a unique id which we could use to refer to a widget. With diffing we have a mix of stale and updated state and generating new ids for something that has not changed complicates everything.
So I'm advocating for stable widget ids. The widget id should be based on the function of the widget, so equivalent functionality will be assigned the same widget id (or checkbox id).
The way @ashishmohapatra240 has suggested does fit the criteria by hashing based on a unique string identifier, but I think this will also prove to be a bit fragile since we could get two checkboxes with the same identifier and it also just does not feel super elegant.
I'd prefer if we assign the id based on the position of the widget in the widget tree and based on the widgets type. This would eliminate the need to try to come up with unique identifier names and we could then actually compare widgets by using their partial eq implementation, simplifying the diffing code and potentially even saving a few lines of code. Thoughts?

[Keavon]

If we dynamically change which widgets are shown, the indexes would shift and old indexes would be associated with different widgets after the change, which would confuse the diffing; right?

[TrueDoctor]

If we include the widget type and potentially content so if the widgets change but are in the same location, they would still get a different id