Throw warning if we can't find condor_chirp
**Impact of the bug**
 Things like cmsRun exitcode won't be set as a condor job classad, hence won't be present in ElasticSearch.

We set different things in the cmssw executor [here](https://github.com/dmwm/WMCore/blob/8864d49526fa57466f3d6cd2d1a2546d38d12dd6/src/python/WMCore/WMSpec/Steps/Executors/CMSSW.py#L50-L59)

But if can't find `condor_chirp`, we simply do nothing.

**Describe the bug**
If `condor_chirp` is not present, we don't throw any errors or warnings here:

https://github.com/dmwm/WMCore/blob/master/src/python/WMCore/WMSpec/Steps/Executor.py#L193-L197

It seems GlideinWMS has recently (1 week ago) started to use a new implementation to provide singularity support at the Submission Infrastucture level, and this has broken `condor_chirp`, which can't be found in the environment anymore. 

**How to reproduce it**
Inject a CMSSW workflow and after it has finished, look for Chirp classads. If not found, chirp didn't do anything. Example:

```
[khurtado@vocms0290 /data/khurtado/chirp]$ condor_history cmst1 -limit 5
 ID     OWNER          SUBMITTED   RUN_TIME     ST COMPLETED   CMD
 106.158 cmst1           5/5  00:10   0+22:01:07 C   5/5  22:19 /data/srv/wmagent/v1.3.3.patch3/sw/slc7_amd64_gcc630/cms/wmagent/1.3.3.patch3/etc/submit.sh amaltaro_TaskChain_Nano
 106.181 cmst1           5/5  00:10   0+20:31:17 C   5/5  20:53 /data/srv/wmagent/v1.3.3.patch3/sw/slc7_amd64_gcc630/cms/wmagent/1.3.3.patch3/etc/submit.sh amaltaro_TaskChain_Nano
 106.182 cmst1           5/5  00:10   0+20:07:36 C   5/5  20:31 /data/srv/wmagent/v1.3.3.patch3/sw/slc7_amd64_gcc630/cms/wmagent/1.3.3.patch3/etc/submit.sh amaltaro_TaskChain_Nano
 179.0   cmst1           5/5  17:52   0+00:00:24 C   5/5  17:58 /data/srv/wmagent/v1.3.3.patch3/sw/slc7_amd64_gcc630/cms/wmagent/1.3.3.patch3/etc/submit.sh amaltaro_TaskChain_Nano
 178.0   cmst1           5/5  15:21   0+02:23:56 C   5/5  17:48 /data/srv/wmagent/v1.3.3.patch3/sw/slc7_amd64_gcc630/cms/wmagent/1.3.3.patch3/etc/submit.sh amaltaro_TaskChain_Nano
[khurtado@vocms0290 /data/khurtado/chirp]$ condor_history 106.158 -l | grep -i Chirp
[khurtado@vocms0290 /data/khurtado/chirp]$
```



**Expected behavior**
We should probably not abort the job, but at least print some warnings in the logfiles so that we can spot this issue.


**Additional context and error message**
Besides condor locally, you can also compare JSON documents from ES from [current dates](https://es-cms.cern.ch/kibana/app/kibana#/doc/AW-jG5fH3kqLbEI6l31t/cms-2020-05-05/_doc?id=vocms0290.cern.ch%23179.0%231588693971%231588694292&_g=()) vs [older dates](https://es-cms.cern.ch/kibana/app/kibana#/doc/AW-jG5fH3kqLbEI6l31t/cms-2020-04-21/_doc?id=cmsgwms-submit5.fnal.gov%23224138.101%231587478882%231587750839&_g=()
) when Chirp classads were present

** Update ** 
Current central chirp issue has been issued a hotfix here:
https://cdcvs.fnal.gov/redmine/issues/24381



diff --git a/src/python/WMCore/WMSpec/Steps/Executor.py b/src/python/WMCore/WMSpec/Steps/Executor.py
index 562ee55da..ab2a2b257 100644
--- a/src/python/WMCore/WMSpec/Steps/Executor.py
+++ b/src/python/WMCore/WMSpec/Steps/Executor.py
@@ -11,6 +11,7 @@ import os
 import sys
 import json
 import subprocess
+import logging
 
 from Utils.FileTools import getFullPath
 from Utils.Utilities import zipEncodeStr
@@ -193,5 +194,11 @@ class Executor(object):
         if condor_chirp_bin and os.access(condor_chirp_bin, os.X_OK):
             args = [condor_chirp_bin, 'set_job_attr_delayed', key, json.dumps(value)]
             subprocess.call(args)
+        else:
+            if condor_chirp_bin and not os.access(condor_chirp_bin, os.X_OK):
+                msg = 'condor_chirp was found in: %s, but it was not an executable.' % condor_chirp_bin
+            else:
+                msg = 'condor_chirp was not found in the system.'
+            logging.warning(msg)
 
         return
['src/python/WMCore/WMSpec/Steps/Executor.py']