fix(port-block): fence only through the SPDK RPC, drop the FirewallClient fallback (R26.3)

[wmousa]

Summary

The control plane now fences ports only through the SPDK RPC, and the iptables firewall-API fallback is gone. This is the control-plane half of ultra #218, which removed iptables and the firewall webapp from the SPDK image (already cherry-picked to every ultra branch from R26.3 up and main).

Commit 1: revert #1484. FENCE_PORTS existed only so the ultra entrypoint could clean up 25.10 fence rules. That entrypoint code is gone, and 25.10.x → 26.3 upgrades are offline, so nothing reads the variable any more.

Commit 2: drop the fallback. port_block.set_port used to send fences to FirewallClient (mgmt_ip:firewall_port) in two cases:

• whenever node.spdk_version == "";
• whenever nvmf_port_block returned method-not-found.

25.10.x node records have no spdk_version, and it is only set by a restart that passes --spdk-proxy-image. Every upgraded node therefore kept "", and every fence on it went to a port that nothing listens on in 26.3. The fence failed with connection refused.

Changes:

• port_block: set_port, get_blocked_ports_set and is_port_blocked use the SPDK RPCs only. Any RPC error, method-not-found included, propagates.
• health_controller.check_ports_on_node: the per-port legacy branch is removed.
• fw_api_client.py: deleted; port_block was its only user.
• Tests:
  • The ftt2 and dual-FT fixtures patch port_block instead of FirewallClient.
  • The expansion simulator answers the three port RPCs instead of stubbing FirewallClient.
  • New regression tests in tests/unit/test_port_block_rpc_only.py, and the old fallback test in test_port_block_leak_k8s_0911.py now asserts that the error propagates.

Test plan

• ruff check, mypy simplyblock_web simplyblock_cli simplyblock_core: clean
• Unit suite: 2773 passed, 7 skipped
• Integration tier (needs FDB; it collects, 278 tests in the touched suites, but was not run locally): CI
• On a cluster upgraded from 25.10 without --spdk-proxy-image: a fence and unfence round-trips through nvmf_port_block / nvmf_port_unblock

Systemic causes

• Which fencing mechanism to use was decided by an image-tag string. It came from spdk_version, derived from the proxy image tag at storage_node_ops.py, rather than from what the SPDK on the node supports. An upgraded record silently picked the dead path.
• Nothing tested the production RPC path. Before this PR no test referenced nvmf_port_block: every fixture node had spdk_version == "", so the integration suites ran fencing through the patched FirewallClient only.
• Left over, not removed here: spdk_version is now unused, and so are the firewall_port field and FW_PORT env, plus the jc dependency. They can go in a follow-up.

Backported from #1497 (main)

• e46e0875e, remove the firewall-port plumbing: firewall_port / FW_PORT, get_next_fw_port, the deprecated /snode/firewall_set_port and /snode/get_firewall routes, spdk_version, and jc (removed from requirements.txt; R26.3 has no uv.lock).
• 79af1723d, remove utils.port_block: callers use node.rpc_client(timeout=…, retry=…).nvmf_port_block/unblock(port) directly, RPCClient.nvmf_get_blocked_ports returns the set of ports, and tests use tests._mocks.route_fences. This is the same change as on main, applied by hand because the branches have diverged: on R26.3 the client calls _request3, and four of main's test files don't exist.
• 4cd415bae: ClassVar fix for RUF012. The Linter installs an unpinned ruff, and 0.17.1 flags ttl_cache.py.

Local check against the branch before the backport (e46e0875e~1):

• Unit suite: 2764 passed in both.
• The integration files this touches, run on mocks with the unit-tier FDB stub: same results before and after. ftt2/test_hublvol_mock_rpc.py is flaky only when two runs share its fixed ports; run alone, it passes 52/52 on both.

🤖 Generated with Claude Code

[Hamdy-khader]

Looks good

[mxsrc]

I like this alot, always in for removing code :D
At this point we can simply remove the port_block module altogether I feel:

• set_port just calls either block or unblock, there's no call sites that don't statically define the block argument so it's a direct call at each site.
• get_blocked_ports_set is the only call-site of RPCClient.nvmf_get_blocked_ports so the projection can just be done in that helper
• is_port_blocked is a simple predicate of that and merits no additional helper

[wmousa]

Agreed, with the fallback gone port_block is a thin layer and can go. I'd rather keep #1496 minimal since it's on R26.3 and gets cherry-picked, and do the removal on main as a follow-up. That means inlining the 13 set_port sites as direct nvmf_port_block / nvmf_port_unblock calls, moving the blocked-ports set into RPCClient.nvmf_get_blocked_ports, and dropping is_port_blocked. Most of the work is the ~40 test files that mock fencing through port_block.set_port, so it's better as its own PR.