Review enums

[schlafly]

@tddesjardins , I went through the schemas looking for more potentially problematic enums along the lines of #889 . There are some other cases where we might consider removing the enum / at least making sure we're happy with the allowed values:

Name	Location	Values	Notes
Exposure type	meta.exposure.type (meta/exposure.yaml)	WFI_IMAGE, WFI_SPECTRAL, WFI_IM_DARK, WFI_SP_DARK, WFI_FLAT, WFI_LOLO, WFI_WFSC	Probably okay? We could remove the enum if we thought there were a meaningful chance of adding a mode on short notice.
Guide window mode	meta.guidestar.guide_mode (meta/guidestar.yaml)	WIM-ACQ, WIM-TRACK, WSM-ACQ-1, WSM-ACQ-2, WSM-TRACK, DEFOCUSED-MODERATE, DEFOCUSED-LARGE	No idea if these are up to date or changeable!
Program subcategory	meta/program.yaml → meta.program.subcategory	CAL, CGI, CR, DR, GBTD, HLTD, HLWA, OR, WFI, WFSC, None	Used in both l3_common and program.yaml as separate enums. Per this discussion, both should be strings.
Aperture name	meta/wcsinfo.yaml → meta.wcsinfo.aperture_name	WFI01_FULL–WFI18_FULL and WFI_01_FULL–WFI_18_FULL, WFI_CEN, BORESIGHT, CGI_CEN	We added both WFI01_FULL and WFI_01_FULL to accommodate some known churn in the siaf file. Do we think these are complete or should we convert to a string?
Visit type	meta/visit.yaml → meta.visit.type	GENERAL_ENGINEERING, GENERIC, PARALLEL, PRIME_TARGETED_FIXED, PRIME_UNTARGETED	This feels like another good candidate for enum -> string to me? Just doesn't feel like a complete / unchangeable list.
FGS modes used	meta/guidewindow_common.yaml → meta.guide_window.fgs_modes_used	NOT_CONFIGURED, STANDBY, WIM_ACQ_VW, WIM_ACQ_NA, WIM_TRK, WIM_TRK_S, WSM_ACQ_HC, WSM_ACQ_VC, WSM_TRK, WIM_DFC	I have no sense for how complete / up to date / changeable these are!
FGS op phase	l1_face_guidewindow.yaml → face_data.fgs_op_phase	(same 10 values as fgs_modes_used)
Origin	meta/origin.yaml → meta.origin	STSCI, STSCI/SOC, IPAC/SSC	Convert to string in case anyone else wants to use this?
RCS LED	meta/rcs.yaml → meta.rcs.led	1, 2, 3, 4, 5, 6, None	Probably okay?
RCS electronics	meta/rcs.yaml → meta.rcs.electronics	A, B, None	Probably okay?
RCS bank	meta/rcs.yaml → meta.rcs.bank	1, 2, None	Probably okay?
Ephemeris type	meta/ephemeris.yaml → meta.ephemeris.type	DEFINITIVE, PREDICTED	Probably okay?
Exposure engineering quality	meta/exposure.yaml → meta.exposure.engineering_quality	OK, SUSPECT	Convert to string to be less restrictive of potential future uses?
Pointing engineering source	meta/pointing.yaml → meta.pointing.pointing_engineering_source	CALCULATED, PLANNED	Maybe okay?
WSM edge used	l1_detector_guidewindow.yaml, l1_face_guidewindow.yaml → meta.wsm_edge_used	blue, red	Could we imagine other modes, e.g., both blue & red?
Pseudo star flag	l1_detector_guidewindow.yaml → meta.guide_star.pseudo_star_flag	Y, N	Not sure.

[schlafly]

@rcosenti-stsci

[tddesjardins]

@schlafly here are my recommendations:

• Exposure type (meta.exposure.type) - keep the enum. This needs to be well-coordinated between products and CRDS.
• Guide window mode (meta.guidestar.guide_mode) - remove the enum. Checking RPSDB, the values in there do not match up with this list, but they may change over time. Best to let PSS set these.
• Program subcategory (meta.program.subcategory) - Per Review subcategory enum #889, remove the enum. This isn't expected to change, but stops validation errors if PSS does modify something (e.g., HLWA -> HLWAS).
• Aperture name (meta.wcsinfo.aperture_name) - These are complete for the foreseeable future. We can keep the enum. The strings like WFI_01_FULL - WFI_18_FULL can be removed.
• Visit type (meta.visit.type) - No problem removing the enum. I don't think this will change, but not a big deal to remove.
• FGS modes used (GW file meta.guide_window.fgs_modes_used) - I would keep the enum and not alter these. This is linked to the flight software and pulled from the telemetry. If we get back something different, we want to know and update RAD.
• FGS Op Phase (FACE file face_data.fgs_op_phase) - Same as FGS modes used. Do not change.
• RCS LED - Okay to leave enum as-is. This needs a re-work when we can update schemas again. I take the blame for not catching this, but it's not just one value but it should be a list of values (and likewise the led fluxes should be a list of values one per element in this list.)
• RCS electronics - Okay to leave enum as-is.
• RCS bank - Okay to leave enum as-is.
• Ephemeris type - Okay to leave enum as-is.
• Exposure engineering quality - Okay to leave enum as-is or to remove enum.
• Pointing engineering source - Okay to leave enum as-is.
• WSM edge used - Okay to leave as-is for now I guess. This is more problematic overall and needs to be re-worked because it's not just one value, it is up to 18 values and they could be all red, all blue, or a mix of red and blue.
• Psudo star flag - Okay to leave enum as-is.