Description of problem:

If target-role=Stopped in rsc_defaults, then running `pcs resource enable <rsc>` on any individual resource or group does nothing. pcs seems to make the assumption that the target-role meta attribute defaults to "Started". Rather than setting `target-role=Started` on enable, it simply unsets the target-role meta attribute.

Likewise with is-managed=false in rsc_defaults. Running `pcs resource manage <rsc>` on any individual resource or group does nothing.

This behavior seems correct when the maintenance-mode or stop-all-resource cluster property is enabled, as that is a cluster-wide setting. However, rsc_defaults are designed to work as just that -- **default** values for meta attributes. Each resource (or group, clone, etc.) should be able to override them.

Explicitly setting target-role=Started on a resource overrides a value of "Stopped" in rsc_defaults. Explicitly setting is-managed=true on a resource overrides a value of "false" in rsc_defaults.

Since we should IMO be able to override the default with `pcs resource enable/manage` (without having to manually update meta attributes), it seems that `pcs resource enable` should set target-role=Started instead of unsetting target-role, and that `pcs resource manage` should set is-managed=true instead of unsetting is-managed. Ken and I discussed this in comments 9 and 10 of BZ1748139.

However, there are some special considerations where I'm not sure what **should** happen.
  1) If a user runs `pcs resource disable <group>` and then `pcs resource enable <rsc>` on a resource within the group:
    a) Should that resource become enabled (i.e., get target-role=Started set)?
    b) Or should the preceding disable of the entire group prevent `pcs resource enable` from setting target-role=Started for any child resources, until target-role=Stopped is removed from the group's meta attributes?
       - If we go this route, we could have a --force flag that allows `pcs resource enable` to set target-role=Started for child resources.

  2) If a user runs `pcs resource enable <rsc>` on some resource within a group, and then `pcs resource disable <group>` on the group as a whole:
    a) Should every resource in the group get disabled (i.e., get target-role=Stopped set)?
    b) Or should target-role=Stopped only be set for the group itself, letting the existing target-role=Started at the resource level override it for individual resource(s)?


A related question is whether we should continue setting target-role and is-managed meta attributes only on the group element and allow children to inherit them, or set the meta attributes on the group element **and** on all child elements. This is relevant because if `pcs resource enable` (with new behavior) has previously set target-role=Started explicitly on child resources, and then we run `pcs resource disable` on the group, then all the children remain enabled unless we iterate over them and set target-role=Stopped (or unset target-role and allow them to inherit from the group).

-----

Version-Release number of selected component (if applicable):

pcs-0.10.4-6.el8_2.1

-----

How reproducible:

Always

-----

Steps to Reproduce:

There are a number of scenarios that would need to be tested, and the expected results will depend on the details of the approach we choose (see Description). The main focus is that `pcs resource enable` should override a resource default of target-role=Stopped, and `pcs resource manage` should override a resource default of is-managed=false.

1. Create a resource called dummy.
2. Set resource defaults to disable and unmanage all resources by default.

    # pcs resource defaults target-role=Stopped
    # pcs resource defaults is-managed=false

3. Enable and manage dummy to override these defaults.

    # pcs resource enable dummy
    # pcs resource manage dummy

-----

Actual results:

dummy remains disabled and unmanaged.

-----

Expected results:

dummy becomes enabled and managed.