New threading model

[andydotxyz]

Checklist

• I have searched the issue tracker for open issues that relate to the same feature, before opening a new one.
• This issue only relates to a single feature. I will open new issues for any other features.

Is your feature request related to a problem?

To work on race conditions and many locking challenges we agreed to revise the threading model (the "App thread").
This issue tracks the work required.

Is it possible to construct a solution with the existing API?

No response

Describe the solution you'd like to see.

First:

• Back out the BaseWidget.SetFieldsAndRefresh API - it will be obsoleted by "fyne.Go"
• Re-merge draw and event into one thread (Revert using a separate draw thread #4656)
• Move animation ticks to the main thread (Revert using a separate draw thread #4656)
• Check that all widget callbacks happen on this same thread (That's the races out of our test suite! #5384)
• Combine data binding into same thread (and remove test waits) (Make data binding thread safe #5361)
• Add ability to schedule code on the App thread (new "fyne.Go" API #6599)
• Enable race on all our CI test runs (That's the races out of our test suite! #5384)
• Add new tests that show that things work as expected from goroutines
• Explicitly document the specific APIs that are still allowed to be called from goroutines without using the above new API. (Possibly only data binding, and various "pure" funcs that don't mutate state?)

Then:

• Clean up now-unneeded locks/synchronization in widgets, etc (Cleanup of unneeded locks in canvas objects #5388)
• Revise unit testing to do this all sync and remove waits etc no longer needed (That's the races out of our test suite! #5384)

Also to consider:

• Fix issues with re-draw on window resize that led to draw/event separation
• Consider adding a noCopy struct that is a dummy implementation of sync.Locker to BaseWidget so go vet can still complain about passing widgets by value

[dweymouth]

Re-merge draw and event into one thread

This might be the easiest path, but it isn't necessarily the only one. We can keep them on separate threads as long as we have them lock when reading or writing state.

That being said, unless we need to work around platform issues (ie #2 on the checklist), merging them to one thread might be the way to go.

I'll also add another checklist item for removing all the now-unneeded locks/sync stuff throughout the codebase

[andydotxyz]

Re-merge draw and event into one thread

This might be the easiest path, but it isn't necessarily the only one. We can keep them on separate threads as long as we have them lock when reading or writing state.

Yes, there could be locking based solutions - but part of this is trying to find the simplest solution, so reverting the thread split seems like a good start.

[andydotxyz]

Work is begun on this - I updated the TODO above to highlight what is needed in the order.
I have a proof of concept for most of the top list working locally and it is indeed race-free but with a significant lag on heavy event usage... more work to do before I open more PRs

[Jacalz]

The no copy idea might be easily solved with this Go proposal once accepted: golang/go#70811