Refactor scheduler plugins; store in a dictionary

[douglasdavis]

• Closes #xxxx
• Tests added / passed
• Passes black distributed / flake8 distributed / isort distributed

Following up on some discussion in #4808, this converts scheduler plugin storage from a list to a dictionary (key: name, value: plugin instance)

[douglasdavis]

OK this is ready for a first review-- the main thing that I'm not sure about is the introduction of names for the builtin plugins. I've implemented name discovery similar to worker plugins: that is, if a name attribute is present on the plugin instance, it is taken as the name to be used as the key in the plugin dictionary. Are there any scheduler plugin classes that are designed/capable of having multiple instances used?

An alternative would be to use the name= argument in the Scheduler.add_plugin method, or add name= to SchedulerPlugin.start(scheduler=..., name=...)

[douglasdavis]

w.r.t. #5120 (comment): Here's an example of giving a name to a builtin plugin

[douglasdavis]

After seeing #5127, perhaps something similar should be done for SchedulerPlugins (a name property which uses tokenize?)

[jrbourbeau]

Thanks @douglasdavis!

[douglasdavis]

Thanks for the feedback @jrbourbeau! I think I covered everything so far, happy to make further adjustments

[jrbourbeau]

Thanks for the updates @douglasdavis! FWIW there's a discussion over in #5127 around how worker and nanny plugins treat repeats different which you may find interesting

[mrocklin]

I need something similar to this for some ongoing work. My apologies for taking over. I hope that you don't mind.

[mrocklin]

This is in. Thank you @douglasdavis

[douglasdavis]

Don't mind at all, thanks for getting it over the finish line