Increase service startup delay for tests that fail the health checks

[jefferbrecht]

Description

The health checks can take up to 30s to time out when they fail. We use a service startup delay of 20s. which is adequate in passing scenarios. However, for tests that deliberately fail the health checks, we need to make sure that the full 30s can lapse before validating the health check results.

Related issue

b/321001728

How has this been tested?

Will let presubmits run.

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.

[franciscovalentecastro]

The previous remote command startCommandForPlatform won't continue until the Health Checks finish executing. So, there is not need to account for the network check backoffs within this tests.

ops-agent/cmd/ops_agent_windows/run_windows.go

Lines 73 to 82 in 11c19c2

	s.log.Info(EngineEventID, "generated configuration files")
	s.runHealthChecks()
	changes <- svc.Status{State: svc.Running, Accepts: cmdsAccepted}
	if err := s.startSubagents(); err != nil {
	s.log.Error(EngineEventID, fmt.Sprintf("failed to start subagents: %v", err))
	// TODO: Ignore failures for partial startup?
	}
	s.log.Info(EngineEventID, "started subagents")
	defer func() {

AFAIU, the flakiness arises (as @jefferbrecht pointed offline) when querying for the service status within getRecentServiceOutputForPlatform(). We could still add some delays, to be sure the status reaches the Windows Event Log or journald.