Separate dmod.communication package into decoupled subpackages

[robertbartel]

Many classes are included in the dmod.communication package. While they all related to communication functionality and share some other similarities, in general, packages depending on dmod.communication get a lot more when installing that package than actually needed.

The solution to this will be to make the package itself more general and move the more usage-specific communication types to isolated, separate namespace packages. These often, if not always, will be service-specific in nature. For example, a dmod.dataservice.communication package will be created for types needed in the communication with the dataservice.

Initially, to keep the python/lib/ and python/service/ directory structure in place and meaningful, these new packages will need to be placed under python/lib/, even though there names are going to be similar to service packages. For example, the aforementioned dmod.dataservice.communication package will need the following directory created:

python/lib/dataservice/dmod/dataservice/communication/

We will want to address the lib/ and service/ directory structure eventually also, but that will need to wait to be handled separately.

SubTasks

Note that other subtasks may need to be added as work progresses.

• [ ] Derive new dmod.dataservice.communication package from classes in dmod.communication
• [ ] Derive new dmod.schedulerservice.communication package from classes in dmod.communication

[aaraney]

It is worth our time to consider replacing setup.py with newer configuration files setup.cfg / pyproject.toml during this effort (#248).

[robertbartel]

Yes, definitely worth considering. I think we should do that for any new packages we create going forward, as long as we can do it in isolation.

If we would have to also make changes to how we assemble any of the other, existing packages, then I think we wait. In that case, we'd want to do the conversions all at once as their own separate task.