Protect against any stomp problems on import

[timj]

The stomp import can succeed but the .cvar access can fail.
Protect against all failures with stomp on import and only
set have_stomp on success.

With conda-forge stomp.py installed with 0.6.7.2 esutil we are seeing the following:

>>> import esutil
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Volumes/MediaHD/Users/timj/work/lsstsw/miniconda/envs/lsst-scipipe-0.6.0/lib/python3.8/site-packages/esutil/__init__.py", line 118, in <module>
    from . import stomp_util
  File "/Volumes/MediaHD/Users/timj/work/lsstsw/miniconda/envs/lsst-scipipe-0.6.0/lib/python3.8/site-packages/esutil/stomp_util.py", line 9, in <module>
    INSIDE_MAP = stomp.cvar.Map_INSIDE_MAP
AttributeError: module 'stomp' has no attribute 'cvar'

0.6.5 worked because it caught all exceptions. This PR reverts to that broader catch.

[esheldon]

Is this some alternative version of stomp?

[timj]

Yes: https://pypi.org/project/stomp.py/

which it turns out is used by our workflow submission system and so clashes with the stomp that esutil thinks it wants.

[esheldon]

I see. Thanks for the PR.

[timj]

@esheldon would it be possible to make a new release with this fix? I don't think I see a release since this PR was merged. We are currently having to pin to an old esutil version to allow our LSST pipelines to run at scale.

[esheldon]

done, v0.6.8