grpc: server-side health check default: 5s->500ms

[jsha]

Since the RA always starts unhealthy (it needs to load overrides), this allows it to become healthy sooner.

This speeds up integration test startup by about 20s, because we start four instances of RA, and they were all waiting on their second internal health check before they could become healthy.

Note that our health-checker binary (used from startservers.py) checks health every 100ms, but no requests are actually sent over the wire because the server side has not sent the client a streaming reply to the HealthClient.Watch() RPC. We do have the option of plumbing things up so that RA can call serverBuilder.healthSrv.SetServingStatus() as soon as its overrides are loaded, which would speed things up a bit more, but this seems good enough for now.

[aarongable]

This means that every SA instance will be doing two SELECT 1s every 500ms, too:

boulder/sa/sa.go

Lines 986 to 997 in c3c1684

	func (ssa *SQLStorageAuthority) Health(ctx context.Context) error {
	err := ssa.dbMap.SelectOne(ctx, new(int), "SELECT 1")
	if err != nil {
	return err
	}
	err = ssa.SQLStorageAuthorityRO.Health(ctx)
	if err != nil {
	return err
	}
	return nil
	}

That's probably fine, but I'm not fully convinced we want to do that in prod.

[jsha]

We actually have a healthCheckInterval setting in the SA (and only the SA), which sets this period differently. I had assumed it was set in prod, but looks like not.

I do think it's fine to do SELECT 1 every 500ms in prod, but I do want to avoid spurious prod changes to resolve slowness in CI. I'll look at other fixes here.