support container remote-node migration 

Container remote-node migration is more complex than baremetal remote-node connection resource migration.   To migrate a container remote-node both the container (virtual resource) and the connection resource tied to the container have to migrate independently of one another.  For this to work, both the source and destination cluster-nodes hosting the container must have access to the container's network regardless of what host the container is currently residing on.

Since it may not always be practical for multiple cluster-nodes to have access to a container's network simultaneously because of whatever network topology is in use, this feature supports two modes.

1. migrate container without migrating the connection resource - This would allow the container to migrate in scenarios where the container's network is not accessible outside of the current host node. The drawback here is that all the resources living within the container have to be stopped before the container is migrated.

2. migrate container with connection resource. This gives us seamless migration of both the container and the pacemaker_remote connection to that container. No resource disruption within the container occurs, but to achieve this both the source and destination host cluster-nodes must have simultaneous access to the container's network.

Item 1 is achieved by setting the 'allow-migrate' meta option on the container resource.

Item 2 is achieved by setting both the 'allow-migrate' and 'remote-allow-migrate' meta options on the container resource. The 'remote-allow-migrate' option indicates that the pacemaker_remote connection resource can migrate with the container.

I'll update the pacemaker_remote section soon with more information on this feature.