Create StateEnum PVs to convert from longout to mbbo

[anderslindho]

Create mbbo SR_X_StateEnum records to convert from longout SR_X_State, to display method names
instead of raw integer values. The State PV tracks which save method is currently active
for each save set.

State values:
 - 0: None
 - 1: Periodic
 - 2: Triggered
 - 4: Timer
 - 12: Monitored (Timer + Change combined)
 - 16: Manual

Value 8 (Change) is not included as it is an intermediate state
that only triggers saves when combined with Timer to form
Monitored.

Non-listed values _can_ occur but do not have enumerations; each loop of plist
processing will first perform saves and then immediately clear the bits.

[simon-ess]

After a fair amount of private discussion about the purpose of this change and the best way to convey the information that it is trying to convey, I think I am happy to accept this change.

On the one hand, it is "technically wrong" in that it doesn't cover all possible states. On the other hand, what it does seem to cover is the most likely ways in a way that provides useful feedback to anyone attempting to access information about the autosave state.

I'm happy to approve this, but it might be nice for some sanity feedback from anyone else (e.g. @anjohnson @keenanlang ): do at any sites combine the various save methods on the same file?

[keenanlang]

do at any sites combine the various save methods on the same file?

I don't believe that any of the beamline IOC's combine different save methods in a singular file. At least not anything even remotely recent.

[anjohnson]

Should the new PVs be added to any of the OPI screens that are included here? I'm seeing $(P)SR_0_State in the save_restoreStatus_more.* files, and in MEDM the bits of the _State values are easily visible because the screen uses a byte widget which shows the individual bits of the status value:

The green PRTCM there is actually a button that when clicked brings up a legend for the bits:

These are engineering screens so the fact that they're a bit cryptic shouldn't be a problem for their intended users, which hopefully explains why there hasn't been a need for something like the StateEnum up to now. If any of the OPIs don't have an equivalent to the Byte widget they might need something like an mbbiDirect to make the individual bits accessible, but I admit that a StateEnum string probably uses a bit less screen real-estate.

What is your use-case that needs this change?

[anderslindho]

What is your use-case that needs this change?

We already have this change in place for us. @simon-ess suggested I submit it also here - I guess to assist users with deobfuscating the record values. So consider this a contribution to assist documentation.

Should the new PVs be added to any of the OPI screens that are included here?

I had no plans to do so. We do not use these screens. I am not sure if I could make that contribution as I never have worked with MEDM displays.

[simon-ess]

I think that given @keenanlang 's comment, I am happy to call this good and merge it in.