added filter for luigi visualizer
Fixes multiple purging bug.

If two worker processes get killed at the same time, we'll add them both to the
task handling queue as failures, then remove one of them from running tasks.
After this, we'll add the other one to the queue and remove it. On the third
attempt at task handling, we'll have the second task in the queue but not in
the running dict, resulting in duplicated error messages and a KeyError when
popping from running.

Even if we cut off the purge loop after it finds its first item, this could
still happen if there is already stuff in the queue or other workers insert
into the queue during/after the loop. In order to cleanly avoid removing items
multiple times, this ignores queue items that aren't in the running dict.
Fix a markup error in luigi/task.py.
Fix another markup in the externalize() function.
Fixes a typo in a variable name in fix_time
Possible flakiness fix for test_dynamic_dependencies

test_dynamic_dependencies has been flaky lately (see #571). I can't reproduce it
locally, so I assume it has something to do with Travis running things more in
parallel than I do. test_dynamic_dependencies uses mktemp, which according to
the tempfile documentation should not be used and causes race conditions in
which another program may get access to the temp file first. Replacing this with
mkdtemp should fix the issue while also clarifying that a temporary directory is
wanted and not a temporary file. I haven't been able to verify that this will
fix the flakiness, but it should probably be done anyway. I also added cleanup.
Merge pull request #574 from Houzz/fix_time_typo

Fixes a typo in a variable name in fix_time
Merge pull request #573 from berkerpeksag/patch-1

Fix a markup error in luigi/task.py.
Merge pull request #576 from Houzz/test_dynamic_dependencies_fix

Possible flakiness fix for test_dynamic_dependencies
Merge pull request #572 from Houzz/multi_purge_bug

Fixes multiple purging bug.
Merge pull request #568 from Houzz/viz_filter_pr

Add a task filter for visualizer
Times out long-running workers

I woke up this morning to find that very few jobs had run overnight because
something weird happened with our hadoop cluster that caused all of our jobs to
hang permanently. When I checked in the morning, all workers were busy running
jobs that had been going for about 10 hours, and thousands of pending jobs that
would normally have been run overnight had piled up.

After killing and restarting all of my workers, everything started running fine
again because whatever weird issue had caused everything to hang was over. In
order to automate this fix, I've added a worker_timeout property to tasks that
tells the worker how long to attempt to run the task before killing it.

This property defaults to 0, meaning do not time tasks out. It can be changed
individually for a task by override or globally for all non-overridden tasks
via client.cfg. This only applies when running with more than 1 worker process,
as we need to run the task in a separate process in order to be able to kill it
after the timeout.