Fix indexing bug in zproc expqa check

[akremin]

Overview

This solves the issue identified in Issue #2342 that was introduced in PR #2306 .

zproc allows many modes to process healpix based redshifts and tile-based redshifts in per-exposure, per-night, cumulative, and custom varieties. Because of this the input structure and handling of information is complex and sometimes dependent on the type of job being requested.

Originally the code looped over expids and night to get the list of expid-night combinations, but these are unique lists of the requested variables rather than index-matched lists. However, for pernight, cumulative, and custom tile-based jobs an exposure_table is populated from the set of nights and then subselected to the requested set of exposure ID's. So this table has the index-matched information we want to use.

This PR updates the code to use the exposure_table for identifying exposure_qa files that are expected to exist. The exposure_table variable should exist for pernight and cumulative jobs, which are the only types that perform the tileqa step that we're updating here.

Test

I ran a test of the failing job (tile=80616 thrunight=20201223) mentioned in the issue. I sym-linked the calibnight, exposure_tables, processing_tables, and exposures directories from kibo; copied the relevant script from kibo; and ran it using this branch. The job succeeded.

Location: /global/cfs/cdirs/desi/spectro/redux/test_kibo
zproc log:/global/cfs/cdirs/desi/spectro/redux/test_kibo/ztile-80616-thru20201223-29816844.log
tileqa log: /global/cfs/cdirs/desi/spectro/redux/test_kibo/tiles/cumulative/80616/20201223/logs/tile-qa-80616-thru20201223.log

[sbailey]

Nice! That was a much cleaner fix than I was expecting. Great that you found a way to update this without having to re-define what the nights variable means and thus potentially break some other piece of the code.