Round up saturation-factor

[gjoseph92]

This would ensure that any worker-saturation value > 1.0 will always result in a worker being oversaturated with at least one task, even for a single-threaded worker.

We don't see a strong signal either way in benchmarking that increasing the saturation factor helps runtime. But consensus is currently that submitting 0 extra tasks to workers feels too radical as an initial change.

For clusters where scheduler<->worker latency is relatively high, giving workers an extra task might make more of a difference than we see in our benchmarks.

Or if data access is very slow, getting a head start and overlapping communication (to a database, S3, etc.) with computation might be more beneficial.

I'm personally still on the fence about this (because it certainly can increase memory usage, but we don't have strong evidence it affects runtime, and it's a little more complicated to explain), but staying a little closer to current behavior seems okay for now.

cc @crusaderky @fjetter @hendrikmakait

• Tests added / passed
• Passes pre-commit run --all-files

[github-actions]

Unit Test Results

See test report for an extended history of previous test failures. This is useful for diagnosing flaky tests.

       15 files  ±    0         15 suites  ±0   6h 18m 58s ⏱️ + 14m 50s
  3 156 tests +    1    3 071 ✔️ +    1    85 💤 +  1  0 ❌  - 1 
23 358 runs  +891  22 449 ✔️ +868  909 💤 +24  0 ❌  - 1 

Results for commit 92e5d0e. ± Comparison against base commit aaab17c.

[crusaderky]

@gjoseph92 This is still in draft state; is anything missing?

[gjoseph92]

@crusaderky I was just waiting for CI. test_cleanup_repeated_tasks was the only failure, which looks unrelated: https://github.com/dask/distributed/actions/runs/3194771817/jobs/5214689413#step:18:1317

This is ready to merge.