Monitor: detect and recover from fast_forward candidate stuck with all WAL sources unhealthy

[dimitri]

Problem

When a failover candidate is assigned fast_forward (its LSN lags a peer
standby that holds more WAL), it must fetch the missing WAL before being
promoted. Two failure modes can produce a permanent liveness deadlock:

1. Self-reference loop (commit 1)
The monitor could select the old primary itself as the WAL source —
get_most_advanced_standby had no caller filter, so a node with the highest
LSN in the group could be handed back to itself. fsm_fast_forward would
then loop forever trying to connect to its own endpoint.

2. Dead WAL source (commit 2)
If the WAL-source standby dies while the candidate is fetching, the candidate
reports back report_lsn (failed fetch) while its goal stays fast_forward.
IsBeingPromoted() locks the monitor into ProceedWithMSFailover, which does
nothing useful because CandidateNodeIsReadyToStreamWAL explicitly excludes
fast_forward. The election cannot restart; the cluster is stuck forever.

Fix

Commit 1 — self-reference filter in get_most_advanced_standby

Add a caller_node_id bigint default 0 parameter to the SQL function and
propagate it from the keeper through monitor_get_most_advanced_standby and
keeper_get_most_advanced_standby. The SQL WHERE clause excludes the calling
node:

AND nodeid != $3

Commit 2 — stuck-detection + health filter

group_state_machine.c — new WalSourceNodesAreAllUnhealthy() helper scans
the group for nodes in {report_lsn, report_lsn} (the WAL-source state).
When every such peer is unhealthy and the candidate is in {report_lsn, fast_forward}, the monitor acts based on pgautofailover.guard_data_loss:

• guard_data_loss = true (default): reset the candidate goal back to
  report_lsn and WARN the operator. The election retries automatically if a
  source recovers. Operators can unblock immediately with:

  pg_autoctl perform failover --allow-data-loss
  

• guard_data_loss = false: log and fall through. The SQL health filter
  (below) excludes unhealthy sources, so fsm_fast_forward finds no upstream,
  skips the WAL fetch, and reports fast_forward as its current state. The
  monitor then assigns prepare_promotion on the next call.

pgautofailover.sql — get_most_advanced_standby adds:

AND (current_setting('pgautofailover.guard_data_loss')::bool OR health > 0)

When guard_data_loss = false, unhealthy nodes are excluded from WAL-source
selection, allowing the candidate to promote with available WAL. When
guard_data_loss = true, the highest-LSN node is returned regardless of
health, preserving the no-data-loss guarantee.

Tests

• src/monitor/sql/fast_forward.sql — SQL regression test: bootstraps a
  3-node formation, manually places the candidate in {report_lsn, fast_forward}
  with the WAL source unhealthy, then verifies:
  • Test A (guard_data_loss=true): node_active returns report_lsn ✓
  • Test B (guard_data_loss=false): node_active returns fast_forward ✓
  • get_most_advanced_standby SQL filter both paths ✓
• tests/tap/specs/fast_forward.pgaf — integration test: kills primary and
  WAL-source standby together, verifies the surviving node stays at
  report_lsn, then unblocks with --allow-data-loss and verifies full
  cluster recovery to primary + secondary + secondary.
• All 9 monitor regression tests pass (make installcheck).
• Style check passes (make docker-check).

Fixes #1060