FIX: metadata handling for enums

[ZLLentz]

Description

Fix three issues related to enum/metadata handling in the SignalConnection part of the SignalPlugin and implement simplified unit tests for these cases.

• Switch the order of the metadata/value setup for new listeners to ensure widgets have the correct contextual information. This is exactly the fix proposed by @canismarko in Initial value is set before enum choices in a PyDMEnumComboBox #605.
• Fix an issue where string=True enum EpicsSignals would reliably break on casting in cases where the enum strings were numerically the same as other indices in the enum_strs tuple. This builds upon the fix proposed by @canismarko in SignalConnection mis-casts the put value from a PyDMEnumComboBox if is_string=True #608
• Fix a related (unreported) issue where the previous point could also break for string=False EpicsSignals.

Motivation and Context

closes #605
closes #608

How Has This Been Tested?

Unit tests were added. I originally tried to make a larger unit test where I instantiated real/fake EpicsSignal instances and connected them to the combobox widgets as reported in the issues, but I couldn't get this to work properly in a unit testing context. Rather than dump additional dev hours into this, I came up with simpler tests, possibly these could be better.

I will need to test with a real EPICS PV too.

Where Has This Been Documented?

I need to write some release notes

Pre-merge checklist

• Code works interactively
• Code contains descriptive docstrings, including context and API
• New/changed functions and methods are covered in the test suite where possible
• Code has been checked for threading issues (no blocking tasks in GUI thread)
• Test suite passes locally
• Test suite passes on GitHub Actions
• Ran docs/pre-release-notes.sh and created a pre-release documentation page
• Pre-release docs include context, functional descriptions, and contributors as appropriate

[ZLLentz]

Interactively, applying this fixed the mix-up between the enum values for putting to a ("1", "2", "5") enum signal but it actually increased the number of error messages I got at startup...

Before:

[2024-06-24 18:02:00,325] [ERROR   ] - Can not change value to '5'. Not an option in PyDMComboBox
[2024-06-24 18:02:00,326] [ERROR   ] - Can not change value to '5'. Not an option in PyDMComboBox

After:

[2024-06-24 18:03:02,868] [ERROR   ] - Can not change value to '1'. Not an option in PyDMComboBox
[2024-06-24 18:03:02,869] [ERROR   ] - Can not change value to '1'. Not an option in PyDMComboBox
[2024-06-24 18:03:02,869] [ERROR   ] - Can not change value to '1'. Not an option in PyDMComboBox

[ZLLentz]

Scratch that- the extra spam errors come from the signal not being fully connected when the widget comes online. Waiting for connection resolves the spam. This isn't something to overlook but it's unrelated to the problem the PR is fixing.

[tangkong]

This looks right to me. All I have to offer is documentation type nitpicks.

Did we ever run into this on our end? Or did we just never set string at all?

[tangkong]

I got confused for a bit about what type this actually ends up as, it's not always a tuple right? Maybe a type hint here would help, since it's buried in send_new_meta?

[ZLLentz]

Let me check, I think it's always a tuple but it might also be a list

[ZLLentz]

It looks like enum_strs is always casted to a tuple when we receive them from the control layer before filling the metadata dictionary, and are again casted to a tuple in describe. I'll annotate this as a tuple.

[tangkong]

TIL you could do this with f-strings. This ends up also printing self, might not be the most helpful. But this is truly a nitpick

[ZLLentz]

Oh shoot I didn't realize this would print self... I'll make some sort of adjustment

[ZLLentz]

Simple rework to put the variable names in myself:

TypeError: Invalid combination: enum_strs=('zero', 'one', 'two') with signal_type=<class 'float'>

[ZLLentz]

Locally at LCLS we hadn't hit this yet for a couple reasons:

• Most of our screens that use EPICS go through the PyDM EPICS plugins instead of through the Typhos signal plugins
• We typically hadn't been setting string=True

[ZLLentz]

Interestingly, as I was testing this, I found that there was also an equivalent issue for string=False signals, but whether this caused an issue depended on the precise implementation of the widget that we're connecting to. In the case of PyDM's combobox the values are sent through as integers, so the int-native signal was unaffected and the string-native signal was broken. A widget which sent the values through as strings would have broken int-native signals in the same way.

[tangkong]

LGTM