After a closer look, I'll take that back.  This function gets called from ``Master.removeWorker``, and ``removeWorker`` itself is mostly called safely and sequentially from within the ``Master`` actor's ``receive`` block (handling ``Terminated``, ``RemoteClientDisconnected`` or ``RemoteClientShutdown`` messages); but ``Master.removeWorker`` is also called directly by the Actor System from ``timeOutDeadWorkers``, which is scheduled in ``Master.preStart``.  That means that there already were concurrency and race issues in ``removeWorker``, and this pull request adds to them with the check-then-set in ``ApplicationInfo.removeExecutor``.

@mateiz It looks to me like ``Master.preStart`` should schedule a new ``WorkerTimedOut`` message to be sent to self (i.e. ``Master``) every ``WORKER_TIMEOUT`` interval, and that ``timeOutDeadWorkers`` should be called from within the ``receive`` block's ``case`` for that message.  That means that there could be messages queued in ``Master``'s mailbox ahead of a ``WorkerTimedOut`` that were issued without the sender's knowledge that one or more workers have timed-out and are now ``DEAD``, but I don't think that there was ever a guarantee or expectation of that information being present and synchronized at senders of messages to ``Master``, so I don't think that queuing ``WorkerTimedOut`` messages instead of jumping the line with a separate ``system`` thread directly running ``timeOutDeadWorkers`` introduces any new problems.