TT-496 Bugfix/uptime checks nodes

[tbuchaillot]

Description

Added 2 configurations options for uptime tests.
disable_management_poller - bool - Disables host checker manager in that gw.
poller_group - string - Adds a postfix to the Poller Cache key. In that way, we can have different pollers for each group.

An example of a config with poller_group:

 "uptime_tests": {
        "disable": false,
        "poller_group":"external",
        "config": {
            "failure_trigger_sample_size": 1,
            "time_wait": 2,
            "checker_pool_size": 50,
            "enable_uptime_analytics": true
        }
    },

An example of a config with disable_management_poll:

 "uptime_tests": {
        "disable_management_polle":true
    },

Related Issue

https://tyktech.atlassian.net/browse/TT-496

Motivation and Context

On sharded gateway environments, each shard / node should have their own Poller / Host checker to do the uptimetest of their APIs. For more context, please check https://tyktech.atlassian.net/browse/TT-496

How This Has Been Tested

Tested with:
2 GWs: poller_group:"a" , db_app_conf_options.node_is_segmented:true and db_app_conf_options.tags:["test"]
1 GWs: poller_group:"b" , db_app_conf_options.node_is_segmented:true and db_app_conf_options.tags:["test-2"]
1 GW : "disable_management_poller":true
1 Pump running with uptime tests configured.

1 API with tag "test" and uptime tests on.
1 API with tag "test-2" and uptime tests on.

In Redis we're going to have 2 Poller:

and in Mongo we're going to have the uptime records for boths APIs.

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• Make sure you are requesting to pull a topic/feature/bugfix branch (right side). If pulling from your own
  fork, don't request your master!
• Make sure you are making a pull request against the master branch (left side). Also, you should start
  your branch off our latest master.
• My change requires a change to the documentation.
  • If you've changed APIs, describe what needs to be updated in the documentation.
  • If new config option added, ensure that it can be set via ENV variable
• I have updated the documentation accordingly.
• Modules and vendor dependencies have been updated; run go mod tidy && go mod vendor
• When updating library version must provide reason/explanation for this update.
• I have added tests to cover my changes.
• All new and existing tests passed.
• Check your code additions will not fail linting checks:
  • go fmt -s
  • go vet

[matiasinsaurralde]

LGTM

[joshblakeley]

Thanks @tbuchaillot this looks good to me.