Implement health endpoint based on MicroProfile Health

[nscuro]

This PR implements health endpoints according to the MicroProfile Health specification.

The new HealthServlet is capable of handling the following request paths:

• / - Will return results of all registered health checks
• /live - Will return only results of registered liveness checks
• /ready - Will return only results of registered readiness checks
• /started - Will return only results of registered startup checks

See also: MicroProfile Health REST interface specification

Individual checks must implement the HealthCheck interface, and must be annotated with either @Liveness, @Readiness, @Startup, or a combination of the same. See Different Kinds of Health Checks.

Implementations of HealthCheck must be registered with a global HealthCheckRegistry instance, e.g.:

HealthCheckRegistry.getInstance().register("some-id", new CustomHealthCheck());

A readiness check for database connections is included in this PR.

Applications built with Alpine can add their own custom checks by following the same pattern:

1. Implement a HealthCheck (here: a liveness check)

package org.dependencytrack.health;

import org.eclipse.microprofile.health.HealthCheck;
import org.eclipse.microprofile.health.HealthCheckResponse;
import org.eclipse.microprofile.health.Liveness;

@Liveness
public class CustomHealthCheck implements HealthCheck {
    @Override
    public HealthCheckResponse call() {
        return HealthCheckResponse.builder()
                .name("custom-check")
                .up()
                .withData("some", "data")
                .build();
    }
}

2. Register desired health checks with HealthCheckRegistry, i.e. in a ServletContextListener

package org.dependencytrack.health;

import alpine.common.logging.Logger;
import alpine.server.health.HealthCheckRegistry;
import alpine.server.health.checks.DatabaseHealthCheck;

import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

public class HealthCheckInitializer implements ServletContextListener {

    private static final Logger LOGGER = Logger.getLogger(HealthCheckInitializer.class);

    @Override
    public void contextInitialized(final ServletContextEvent event) {
        LOGGER.info("Registering health checks");
        HealthCheckRegistry.getInstance().register("database", new DatabaseHealthCheck());
        HealthCheckRegistry.getInstance().register("custom", new CustomHealthCheck());
    }

}

3. Mount HealthServlet via web.xml

<servlet>
    <servlet-name>Health</servlet-name>
    <servlet-class>alpine.server.servlets.HealthServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>Health</servlet-name>
    <url-pattern>/health/*</url-pattern>
</servlet-mapping>

Example Responses

Given the database check included in this PR, and the example custom check shown above, responses of the different endpoints would be as follows:

1. /

{
    "status": "UP",
    "checks": [
        {
            "name": "custom-check",
            "status": "UP",
            "data": {
                "some": "data"
            }
        },
        {
            "name": "database",
            "status": "UP",
            "data": {
                "nontx_connection_pool": "UP",
                "tx_connection_pool": "UP"
            }
        }
    ]
}

2. /live

{
    "status": "UP",
    "checks": [
        {
            "name": "custom-check",
            "status": "UP",
            "data": {
                "some": "data"
            }
        }
    ]
}

3. /ready

{
    "status": "UP",
    "checks": [
        {
            "name": "database",
            "status": "UP",
            "data": {
                "nontx_connection_pool": "UP",
                "tx_connection_pool": "UP"
            }
        }
    ]
}

5. /started

{
    "status": "UP",
    "checks": []
}

As per the spec, the status codes returned by those endpoints are:

• 200 - When all checks yield an UP response
• 503 - When at least one check yields a DOWN response
• 500 - When something failed while determining the status or executing checks

Addresses #22

[stevespringett]

Is this ready for merge?

[nscuro]

@stevespringett Yes, ready from my side.

[nscuro]

Changed the way health checks are registered to a global singleton registry pattern.

Service providers and ServiceLoader are a bit too unwieldy I think, and make it unnecessarily hard to test the servlet.

Updated PR description accordingly. Definitely ready to merge now.