Design of Jobs API for plugin / app developers

[cardoe]

I've created a few issues around some type annotation and idiomatic style awkwardness I've felt exist with the Jobs API from the standpoint of nautobot-plugin-ssot. I'm creating this as an overall discussion item because I think there should be some conversation around the design of the API so that you can ensure it's idiomatic and hard to do the wrong thing. The things I've noticed:

1. App / Plugin / Job Developers are encouraged it seems to use the nautobot.apps module. I think this makes sense overall as it would allow the core project to iterate while maintaining a stable API for plugins / jobs to consume. However:

• the examples everywhere don't use it Update docs code samples to use apps imports #4460
• not everything is exported that's used (mentioned in Update docs code samples to use apps imports #4460)
• maybe too much is exposed as well?

2. The way to define a Job conflicts with nautobot-plugin-ssot's style of passing variables around from a type annotation standpoint, mentioned in Think through 2.x style run() implementation and best practice nautobot-app-ssot#272
3. The way to consume the logger is a bit muddy and there's many examples and the docs seem to encourage any usage. Probably should have one consistent way that takes into account nautobot-plugin-ssot's case (but don't pass job=self)
4. The grouping behavior of setting name at the top level of the module is awkward now that you have to call register_jobs(). A better approach would probably be to have register_jobs() take a kwarg of name or grouping and pass that in and it would cover all jobs that were passed in.
5. Need to think about and expand on examples around testing jobs inside of plugins or repos. The way tests are run it causes almost no code to be tested in nautobot-plugin-ssot.