Here's what we need to do:

1. Back versioned attrs out of the 7.3 schema
2. Set LRMD_PROTOCOL_VERSION back to 1.0 in 7.3 builds

The only other API change is remote_proxy_check() but that will fail gracefully.
So going back to a value of "1.0" is safe[1] and would mean that
either side can be updated in any order - this time.
In the future, cluster nodes would _all_ need to be updated prior to
touching _any_ remote ones.

Aside: the reason we want the cluster version to be higher (even
though its the client) is because potentially pacemaker remote could
be on a guest that cannot or should not be updated.  Eg. It hosts a
service that requires an old version RHEL.

Then, once 7.3 is out the door:

3a. Either prevent versioned attributes from being used when old
remotes are around, or
3b. Implement a graceful failure mode (like using the version from the
lrmd instead of the remote)
4. Add versioned attrs back to the schema and bump LRMD_PROTOCOL_VERSION
5. Add a "review lrmd changes that might require bumping
LRMD_PROTOCOL_VERSION" to the upstream release checklist
6. Ensure that new lrm features think about how to handle "old"
remotes in the future
7. Update the docs to indicate that the software version on remote
nodes must be lte the lowest version in the main cluster

[1] It's a possibility that I never intended to commit the "1.1"
change and it was actually a testing artefact.

Update: versioned attributes were not included in 7.3, and it has been determined that the protocol version change was not strictly necessary in any case, so Comment 1's step 2 is sufficient to fix the issue (steps 5-7 are still worthwhile for the future) .

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1862