JP-3662: skip photom step for SOSS full-frame non-TSO exposure

[emolter]

Resolves JP-3662

Closes #8572

This PR addresses a bug running the spec2 pipeline on a NIRISS SOSS exposure taken with full-frame readout and in non-TSO mode. Both the extract_1d and photom step should be skipped for this mode, but the hook in photom that ensures it is skipped when extract_1d is skipped did not catch this exposure type. This has been fixed.

Checklist for PR authors (skip items if you don't have permissions or they are not applicable)

• [x] added entry in CHANGES.rst within the relevant release section
• [x] updated or added relevant tests
• [x] updated relevant documentation
• [x] added relevant milestone
• [x] added relevant label(s)
• [x] ran regression tests, post a link to the Jenkins job below. How to run regression tests on a PR
• [x] All comments are resolved
• [x] Make sure the JIRA ticket is resolved properly

[emolter]

regression tests started here

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 50.00000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 59.54%. Comparing base (d668926) to head (b703a03). Report is 6 commits behind head on master.

Files	Patch %	Lines
jwst/pipeline/calwebb_spec2.py	0.00%	2 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #8575 +/- ## ========================================== + Coverage 59.51% 59.54% +0.03% ========================================== Files 391 391 Lines 39254 39288 +34 ========================================== + Hits 23362 23396 +34 Misses 15892 15892 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[emolter]

single regtest failure is unrelated

[hbushouse]

@emolter So I'm curious as to what kind of outputs, if any, now get created by the Spec2 pipeline in this instance. I assume that a "cal" file is created and that it has all the normal calibrations up to the point of the extract_1d step, so it's a useful product. But is an "x1d" file created and, if so, what kind of content does it have? Is it actually a copy of the "cal" data that's simply labeled as an "x1d" file? Or is there no "x1d" file at all?

[emolter]

@hbushouse no x1d file is created at all. Hopefully that doesn't cause problems downstream?

[hbushouse]

@hbushouse no x1d file is created at all. Hopefully that doesn't cause problems downstream?

I believe that should be OK. The x1d products from level-2b processing aren't used downstream anyway and they just won't show up in the archive.