Throttle tasks based on presence of a scheduler

[danielmitterdorfer]

Previously Rally has considered a task only throttled if it specified a
target throughput. This assumes that there is a meaningful target
throughput to specify though. Consider a more complex case where we want
to simulate a traffic pattern that changes over the course of a
(simulated) day. In that case there is no single "right" target
throughput that can be specified.

With this commit we consider tasks also throttled if no target
throughput is specified but the user has supplied a scheduler
explicitly. We assume that the scheduler will use different parameters
specified on the task to determine its behavior.

[gingerwizard]

I believe we're going to have other issues here. In the UnitAwareScheduler we delegate to the underlying scheduler but don't consider which API is being used - specifically line 288

self.scheduler = self.scheduler_class(self.task, target_throughput)

Where as https://github.com/elastic/rally/pull/1109/files#diff-06ef37921d5086a4d08c6751e12eca6478037b37e832e2e7972d23ba1b3468ceL107 we only pass one parameter. We define the advanced interface as needing just the task.

[danielmitterdorfer]

In the UnitAwareScheduler we delegate to the underlying scheduler but don't consider which API is being used

It is a precondition of the UnitAwareScheduler that only "simple" scheduler classes are passed in its constructor and this is checked in:

rally/esrally/driver/scheduler.py

Lines 102 to 104 in 8961770

	elif is_simple_scheduler(scheduler_class):
	logger.debug("Treating [%s] for [%s] as a simple scheduler.", scheduler_class, task)
	return UnitAwareScheduler(task, scheduler_class)

[gingerwizard]

@danielmitterdorfer some test failures here. Change in principle makes sense once the int tests are fixed.

[danielmitterdorfer]

@danielmitterdorfer some test failures here. Change in principle makes sense once the int tests are fixed.

The test failure has been caused by a misclassification of the UtilizationScheduler class. Previously a scheduler was classified as "legacy scheduler" iff it had exactly two constructor parameters (self and params) and one of them was called params. However, the constructor signature of UtilizationScheduler is:

def __init__(self, params, perf_counter=time.perf_counter):

The additional parameter is needed for unit tests but prevented classification as a legacy scheduler. I have loosened the check now in 9b72a3c and fixed a follow-up issue uncovered by the tests in c8c70b2. IMHO it's ok to be a bit lenient here because we should remove support for legacy schedulers (along with this check) with Rally 2.1.0.

[gingerwizard]

LGTM