reintroduce health liveliness check

[abernix]

We removed the previous health check as a requirement of #1765 and finished that work in #1766, with full-intention of reintroducing it when we had a bit more time to design its features, ports, etc. Some of this was caught up with socket address listener time-constraints in getting the 1.0.0-rc.0 out the door with a desire to limit breaking changes.

We're still going to need some time to design a more fully developed health check, but a couple things are immediately true about the suggestion to use a basic GET GraphQL request as the health check:

• Not all utilities that send HTTP requests actually support sending HTTP headers, as we note is required in our health check documentation

  While not the immediately identified hurdle in that issue, this is very likely to become the next hurdle a user using AWS ALB health checks will encounter in New healthcheck path is not compatible with AWS ALB #1852 after addressing the initial challenge they identified (URL encoding). We fully believe this is going to be a challenge for other non-health-check tools, but as of today, health checks are a pressing need.

• Providing these headers (or at least some headers) is required to satisfy the CSRF protection introduced in feat: CSRF plugin #1006 (which matches the implementation in Apollo Server), even on GET requests.

We'll need to reintroduce a simple health check for now and build out that functionality to enable users to integrate with existing tools without as much friction as they're currently encountering. In the future, we want to consider the impact of CSRF protections on GET requests, but we shouldn't make rapid moves here without consulting with our security focused partners.

For now, let's bring back a liveliness check

[glasser]

Just as a note in support of this: one reason that the Apollo Server non-GraphQL health check felt problematic was that it wasn't actually coordinated with the server's ability to server GraphQL results — for example, it was still healthy even if the server had not properly loaded a schema. I would expect that in the context of Router it would be easier to ensure that the health check checks for more than just "is the process running" and could be based on that as well (though I suspect Router probably doesn't start listening at all without a schema?)