Represents the "set" logic as applied to one of the name=value pairs supplied by the user.
We have to be able to provide the list of AccessChecks for authorization before we perform the actual changes to the configuration. So where the code used to actually make changes to the config it now creates an instance of the right kind of set action. Depending on what dotted name the user provides, the corresponding set action can either apply to a property or something else, and these are handled quite differently.
The original code was fairly complicated, so I have tried to disrupt it as little as possible while describing the general approach in comments as I moved the update logic into these action-related classes. My goal was to retain essentially the same code paths for the various cases, except that originally the intricate logic led to the actual config updates; now essentially that same logic leads to the creation of "action" objects representing the config updates to apply. Once the actions that the command needs to perform are known so are the access checks to be submitted as part of authorization. If the authorization succeeds then the command just runs the correct, previously-created set action to perform the config update(s).