Fix TestNetworkHealthCheck flakiness by waiting for logging and monitoring endpoints to block

[rafaelwestphal]

Description

Updates waitForNetworkBlock in integration_test/ops_agent_test/main_test.go to explicitly verify that logging.googleapis.com and monitoring.googleapis.com are blocked (in addition to telemetry, dl, and packages) before proceeding with the network health check assertions.

Why

When the DenyEgressTrafficTag (test-ops-agent-deny-egress-traffic-tag) is attached to a test VM, GCE firewall rule enforcement propagates across different destination IP routing tables with eventual consistency.
Previously, waitForNetworkBlock only checked whether telemetry.googleapis.com, dl.google.com, and packages.cloud.google.com were blocked. Once those three endpoints timed out, the test runner immediately executed the agent's health checks. However, connections to logging.googleapis.com and monitoring.googleapis.com would frequently remain open for a few seconds longer, causing TestNetworkHealthCheck to fail when the API checks unexpectedly returned PASS instead of FAIL.

Related issue

b/532086232

How has this been tested?

Checklist:

• Unit tests
  • Unit tests do not apply.
  • Unit tests have been added/modified and passed for this PR.
• Integration tests
  • Integration tests do not apply.
  • Integration tests have been added/modified and passed for this PR.
• Documentation
  • This PR introduces no user visible changes.
  • This PR introduces user visible changes and the corresponding documentation change has been made.
• Minor version bump
  • This PR introduces no new features.
  • This PR introduces new features, and there is a separate PR to bump the minor version since the last release already.
  • This PR bumps the version.

[LujieDuan]

LGTM!