portblock: monitor needs to also check state file of inverse action

[lge]

portblock: derive state file from parameters instead of instance

The expected usage of this agent is to pair a "block" with an "unblock", and order startup and configuration of some service between these.

The established idiom is to have two separate instances with inverse actions.
To "reliably" report the status of "block" during a monitor action, it is not sufficient to check the existence of the blocking rule.

It is also insufficient to rely on the pseudo resource state file of this instance only.

To know our actual expectation, we need to check the state file of the "inverse" instance as well.

Because we don't know the OCF_RESOURCE_INSTANCE value of the other instance, we override the state file name for both instances to something derived from our parameters.

This should give use the same "global state" view as the "promotion score" does for the promotable clone variant of this agent.

Fixes regression introduced with 344beb1 status_check=rule (and set that as default), which breaks existing setups requiring user interaction. See also #2099. Alternative to #2107.

Also: add save_tcp_connection to monnitor for promoted action=unblock instance

[oalbrigt]

This will make the metadata suggest it's not running the rule check by default, so I think we should move this down to where you define state_file_base and modify OCF_RESKEY_status_check instead of the default.

[lge]

We could even change the semantics a bit, if we wanted to: up to now, the rule was only active if "block" was started, but "unblock" was not yet started. With "promotable", I think you changed that to "rule present unless unblock promoted", so rule even present after stop.

If we change the two-instance variant to
test $state_unblock -nt $state_block && rule should NOT be active || rule should be active
we get the same semantics.

#!/bin/bash
    state_str=(ALLOW BLOCK);
    for state in "" b "ub" "u b" "b u" u; do
        rm -f block unblock;
        for action in $state; do
            case $action in 
                u) touch unblock;;
                b) touch block;;
                
                # "ambiguous" highly unlikely: both exist, identical timestamps
                ub | bu) touch block unblock;;
            esac;
            sleep 0.1; # so we don't get accidentally get identical timestamps
        done;
        printf "%4s: should %s\n" "$state" "${state_str[$(test unblock -nt block && echo 0 || echo 1)]}";
    done

gives

    : should BLOCK
   b: should BLOCK
  ub: should BLOCK
 u b: should BLOCK
 b u: should ALLOW
   u: should ALLOW

Though that may again violate expectations of existing setups (no rule present if both instances stopped).
Existing setup expectations would be $(test block -nt unblock && echo 1 || echo 0),
which changes above for "": ALLOW, ub: ALLOW (rest is identical).
I'll think about this some more.

Pre-calculating the expectation like that could also simplify the status function.

[oalbrigt]

It would be nice if it has no rule when it's stopped even when action=unblock.

The important thing is that it starts & demotes to the opposite of the specified action, and promotes to the specified action. And monitor checks for that result.