restore select_mock_targets to working order

[moustakas]

[WIP]

Building on #786, and on the heals of the major fixes in the template-generating code in https://github.com/desihub/desisim/pull/559, the purpose of this PR is to restore select_mock_targets to working order (it's been broken for many months, if not a year) and to address a number of open bugs and issues, including #735, #745, #747, and others.

[coveralls]

Coverage remained the same at 56.466% when pulling 83c8a2421dcb6f91550b717804e57c7985cfcf0d on mock-fixes into d26a11443d93328f6579b95583d35e2621416768 on master.

[moustakas]

@geordie666 @weaverba137 @sbailey this PR is now ready for review. However, I need help setting up the unit tests to test the mock code (specifically, test/test_mock_build), which will need to bring in desisim@master as a dependency (at least until we cut a new tag).

For the record, the mock unit tests pass with a local check-out of this branch using

source /global/cfs/cdirs/desi/software/desi_environment.sh master

A couple quick notes:

• I was originally developing and testing this branch on my laptop but I ran into this issue using desitarget.internal.sharedmem--https://github.com/rainwoodman/sharedmem/issues/24 However, when I switched to NERSC I didn't run into this issue. Nevertheless, it'd be good to keep an eye on this change since most of the production desitarget code uses this module.

• This PR commits a new notebook which develops Gaussian mixture models for the various target classes using DR9 photometry, doc/nb/gmm-dr9.ipynb, which may be of interest to others and for other projects.

• There are many(!) places where select_mock_targets could be improved based on actual DESI data and updated cosmological mocks. However, that work is outside the scope of this PR, whose goal was to just get everything back into a working state.

[weaverba137]

For the record: it looks like desitarget already depends on desisim, and of course, desisim already depends on desitarget. Thus we have a circular dependency. It hasn't caused problems so far, but those are always a potential source of pain.

For the sharedmem issue, it would be interesting to compare what version of Python you are using on your laptop to the version at NERSC. If you're using the DESI software stack at all, I think that is still Python 3.8, which would appear to contradict the ticket.

[moustakas]

For the sharedmem issue, it would be interesting to compare what version of Python you are using on your laptop to the version at NERSC. If you're using the DESI software stack at all, I think that is still Python 3.8, which would appear to contradict the ticket.

On my laptop I was using Python 3.8.12 vs Python 3.8.3 for the DESI software stack. I didn't dig any deeper into the issue other than to celebrate when everything "just worked" after I switched from my laptop to NERSC.