POC: Use echo.vue autoconnect instead of GlueState

[astrofrog]

Description

This is not ready for review or testing at this point, I am just opening it to not lose track of it

This is a companion PR to glue-viz/glue-jupyter#529 to see if we can avoid using GlueState here and instead use the use echo.vue autoconnect functionality.

The short version is that at the moment, glue-jupyter and jdaviz rely on GlueState, which basically makes it so that if any property on a python glue state is changed, the whole state class is serialized and sent to the frontend. Likewise, if anything so much as a toggle gets flipped in vue, the whole glue state gets sent back to Python.

This is not ideal in terms of communications but also can cause issues if python properties are linked (this came up while trying to implement log axes support, whereby x_log changing means x_min/x_max changes. What this means is that if x_log changes in the frontend, x_log along with x_min/x_max and other properties get sent back to Python. Python then sees x_log has changed so then changes x_min/x_max to match. However then these look different from the values being sent back from JS, so then it overwrites x_min and x_max.

I have instead been working on a mechanism that will automatically create all the traits needed on a vuetify widget and sync them atomically with the glue state. This means that only the necessary changes get transferred over between Python and JS, and also avoids the issues similar to the log one above.

The main change API-wise is that Application would now have traits for all the properties in the state class.

Change log entry

• Is a change log needed? If yes, is it added to CHANGES.rst? If you want to avoid merge conflicts,
  list the proposed change log here for review and add to CHANGES.rst before merge. If no, maintainer
  should add a no-changelog-entry-needed label.

Checklist for package maintainer(s)

This checklist is meant to remind the package maintainer(s) who will review this pull request of some common things to look for. This list is not exhaustive.

• Are two approvals required? Branch protection rule does not check for the second approval. If a second approval is not necessary, please apply the trivial label.
• Do the proposed changes actually accomplish desired goals? Also manually run the affected example notebooks, if necessary.
• Do the proposed changes follow the STScI Style Guides?
• Are tests added/updated as required? If so, do they follow the STScI Style Guides?
• Are docs added/updated as required? If so, do they follow the STScI Style Guides?
• If new remote data is added that uses MAST, is the URI added to the cache-download.yml workflow?
• Did the CI pass? If not, are the failures related?
• Is a milestone set? Set this to bugfix milestone if this is a bug fix and needs to be released ASAP; otherwise, set this to the next major release milestone. Bugfix milestone also needs an accompanying backport label.
• After merge, any internal documentations need updating (e.g., JIRA, Innerspace)?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.64%. Comparing base (5cf9f62) to head (bc3fe95).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4112   +/-   ##
=======================================
  Coverage   84.64%   84.64%           
=======================================
  Files         204      204           
  Lines       30171    30174    +3     
=======================================
+ Hits        25537    25540    +3     
  Misses       4634     4634           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[astrofrog]

One thing that occurred to me is that we could also auto-add a prefix on the traits that are auto-generated on Application, e.g. state_drawer_content instead of drawer_content - the names would then look similar to before at least and would separate out the auto-generated traits from other ones.

[astrofrog]

This is now ready to review/try out - I implemented the change which means that the properties in the vue file and the auto-generated traits have a state_ prefix. Note that on the Python side, app.state.<property> will continue to work as before, so there is no API breakage.

As we discussed before, if you are still planning to have a big release soon it probably makes sense to defer merging this to after though.