adding multiple keys logic in analytics cache purger for slave gateways (#3487)
adding multiple keys logic in analytics cache purger for slave gateways (#3487)

<!-- Provide a general summary of your changes in the Title above -->

## Description
<!-- Describe your changes in detail -->
Extends https://github.com/TykTechnologies/tyk/pull/3483
Modified the logic for rpc_analytics_purger so it can read from keys from multiple keys. It's coded in full backward-compatible mode, which means that it's going to look for `tyk-system-analytics` key and then for `tyk-system-analytics_X `where X goes from 0 to 9.

After reading, it will send the analytics records to sink through RPC. If tyk-sink has enable_multiple_analytics_keys = true, it will write the records in multiple keys and if it's false, it will write them in only one key.

## Related Issue
<!-- This project only accepts pull requests related to open issues -->
<!-- If suggesting a new feature or change, please discuss it in an issue first -->
<!-- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!-- Please link to the issue here -->
https://tyktech.atlassian.net/browse/TT-1574
## Motivation and Context
<!-- Why is this change required? What problem does it solve? -->
Reduce Redis overload and have a better analytics distribution across the cluster for slave gateways.

## How This Has Been Tested
<!-- Please describe in detail how you tested your changes -->
<!-- Include details of your testing environment, and the tests you ran to see how your change affects other areas of
the code, etc. -->

## Screenshots (if appropriate)

## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [X] 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
<!-- Go over all the following points, and put an `x` in all the boxes that apply -->
<!-- If you're unsure about any of these, don't hesitate to ask; we're here to help! -->
- [X] 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`!
- [X] 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.
- [X] All new and existing tests passed.
- [X] Check your code additions will not fail linting checks:
  - [X] `go fmt -s`
  - [X] `go vet`

lonelycode/tyk,lonelycode/tyk,lonelycode/tyk