Previously, after writing a config update, API clients could do
a /status query to the same node and not see any nodes (including
the leader that they just PUT to) reflect the new version.

With this change, if the client is talking to the controller leader,
it will reliably see the new config version reflected in the /status
result when querying the same node again after a PUT.

This is a little subtle and later we should make simpler rules
for this via a higher level "wait for status updates" as part
of the PUT call itself: redpanda-data#5833

Related: redpanda-data#5609

This tests the new behaviour in the previous commit.

If we query another node, it is possible to see persistent
status updates for the nodes _other_ than the one we are
querying, and non-persistent update to the stauts of the node
we are querying, that passes the version check.

Then if we query status on a different node a moment later,
we will see an older state for the node we first queried.

This only matters for tests that are actively trying to read the
status _again_ after wait_for_version_sync.  wait_for_version_sync
was already correct inasmuchas when it complete the config has
been applied everywhere.