Improve AbstractHealthAggregator to allow customization of aggregated details

[vpavic]

ATM AbstractHealthAggregator allows customization of how aggregated status is calculated, but does not allow users to specify their own representation of aggregated details. And due to aggregate method being declared as final there is no elegant way of making such customization.

This PR adds abstract method to allow the subclasses to define how aggregated details are constructed.

Motivation:
In our current project we integrate with a proprietary external system. To monitor the connection(s) to this system we have implemented custom HealthIndicator. Usually there are multiple instances of this system, with number of instances being determined in runtime. To represent the health of connection we use CompositeHealthIndicator which is composed of multiple instances of our custom HealthIndicator which, by default (OrderedHealthAggregator is being used), results in the following health output:

{
    // other health checks omitted for brevity
    "custom": {
        "custom_1": {
            "status": "UP", 
            ...
        }, 
        "custom_2": {
            "status": "UP", 
            ...
        }, 
        "custom_3": {
            "status": "UP", 
            ...
        }, 
        "status": "UP"
    }, 
    "status": "UP"
}

However, due to dynamic nature of number of nested HealthIndicators the desired representation of details would be an array:

{
    // other health checks omitted for brevity
    "custom": {
        "nodes": [
            {
                "status": "UP", 
                ...
            }, 
            {
                "status": "UP", 
                ...
            }, 
            {
                "status": "UP", 
                ...
            }
        ], 
        "status": "UP"
    }, 
    "status": "UP"
}

I've signed the CLA.

[philwebb]

I tweaked the code a little so that the aggregateDetails method is implemented in AbstractHealthAggregator. It's protected, so you can still override it but I wanted to make sure existing subclasses didn't break on the upgrade.

Thanks for the suggestion and the pull-request!

[vpavic]

Great, thanks Phil! 👍

The idea of moving aggregateDetails implementation into AbstractHealthAggregator came across my mind a day or two after creating the PR but I forgot to push the update.