Inline fail_job_async (#3318)

This should not change any behaviour.

The call happens only in one place, and it only modifies a block-related data
structure, right next to code that more directly modifies block-related data
strucutres.

This PR makes all of those block-related data structure changes happen at the
same level.

This call is not asynchronous, and this PR also removes that confusing use of
the term async - there is a historical reason,

parsl/executors/status_handling.py

@@ -102,12 +102,6 @@ def status_polling_interval(self):
         else:
             return self._provider.status_polling_interval
 
-    def _fail_job_async(self, block_id: str, message: str):
-        """Marks a job that has failed to start but would not otherwise be included in status()
-        as failed and report it in status()
-        """
-        self._simulated_status[block_id] = JobStatus(JobState.FAILED, message)
-
     @abstractproperty
     def outstanding(self) -> int:
         """This should return the number of tasks that the executor has been given to run (waiting to run, and running now)"""
@@ -198,8 +192,7 @@ def scale_out(self, blocks: int = 1) -> List[str]:
                 self.job_ids_to_block[job_id] = block_id
                 block_ids.append(block_id)
             except Exception as ex:
-                self._fail_job_async(block_id,
-                                     "Failed to start block {}: {}".format(block_id, ex))
+                self._simulated_status[block_id] = JobStatus(JobState.FAILED, "Failed to start block {}: {}".format(block_id, ex))
         return block_ids
 
     @abstractmethod