(Note: It's possible we already do this, or that somehow we effectively do due to things blowing up if the rule is broken.)

We have always had a rule that the DC must be running the latest version of the software. If it isn't it can't reliably manage slaves as it cannot know how the slaves will interpret the operations it sends to them, and slaves will assume that the master is sending operations that are tailored to the management API versions it sent when it registered.

I do not believe the software actually enforces this requirement though. With the more complex use cases that WFCORE-338 will introduce we need to make this more formal.

When a slave first contacts a master it provides its kernel API version with the HostInfo data it sends over and then later in the registration process it provides the subsystem API versions for all the extensions the master provided. Both of these points provide an opportunity for version comparison.

When an HC rejects registration by a slave, we have a mechanism for propogating an error code to the slave to help it understand and report the problem (e.g. the remote HC is not master or it is running in admin-only mode.) We should try to expand that mechanism to include this case, rather than failing with a general unspecified error.