plugin results: support overwriting when data loaded in multiple viewers

[kecnry]

Description

This pull request extends the support for the plugin results mixin to properly handle overwriting an existing data entry when that data entry is already loaded in multiple viewers (the case of a single viewer was previously supported). This is not currently used in jdaviz, but will be by lcviz (and could be by jdaviz if we ever want to support creating multiple spectrum viewers in any of the configs).

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?
• 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.
• After merge, any internal documentations need updating (e.g., JIRA, Innerspace)?

[codecov]

Codecov Report

Patch coverage: 96.15% and project coverage change: -0.01 ⚠️

Comparison is base (1d5a57a) 91.59% compared to head (7cd7129) 91.59%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2222      +/-   ##
==========================================
- Coverage   91.59%   91.59%   -0.01%     
==========================================
  Files         148      148              
  Lines       16496    16506      +10     
==========================================
+ Hits        15110    15118       +8     
- Misses       1386     1388       +2     

Impacted Files	Coverage Δ
jdaviz/core/template_mixin.py	93.10% <96.15%> (-0.13%)	⬇️

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[pllim]

#yolo

[rosteen]

when that data entry is already loaded in multiple viewers

About to start testing, it seems like there might be a way to get here in Imviz. Or are none of the Imviz plugins applicable to this?

Edit: never mind, I was thinking maybe with Gaussian Smooth, but that's not in Imviz anymore.

[kecnry]

Or are none of the Imviz plugins applicable to this?

I guess it is possible to trigger this in cubeviz by creating a moment map, sending it to the uncertainty viewer, manually adding it to the flux viewer, and then overwriting. Is that worth using that case to get coverage? Practically I think this will be more useful in jdaviz if/when we support multiple spectrum viewers.

When you do that, you'll see that this PR tells the user that the visibility will be assumed from the current entry in all/any viewers (and should work):

[rosteen]

Ahh good call on Cubeviz, I tested there with Gaussian Smooth and it seemed to work as expected. I guess you could add coverage using the Cubeviz case...half of me wants to say add that before merging, half wants to say go ahead and merge without.

[kecnry]

All the python lines (with the exception of a somewhat unrelated typo fix which we never used) are currently covered by existing tests for the single-viewer case (basically one iteration of the for-loop instead of multiple) and the UI itself isn't currently feasible to check, so maybe that's good enough for now until there is a more realistic workflow to actually test against? We're at least safe that those lines are covered and don't cause crashes.

[rosteen]

I think it's fine then. I ran into one bug that I want to confirm exists on main before I approve.

[rosteen]

The other bug I found exists in main, approved.

[rosteen]

FWIW the bug I ran into is #2085