Implement limit on tag cardinality of check results

[vibhory2j]

The underlying time series backend gets under pressure due to high cardinality on the tags (metadata that characterises the metrics) associated with check results. The current implementation processes unlimited number of tags and forwards them to the time series backend for storage.

Check results are provided to data-service at per entity level containing tags produced as per check definition. There are checks which produce large number of tags(key results) and sometimes with unique name every execution resulting in explosion in tag cardinality.

This issue is created to validate hypothesis and implement that the tags cardinality (and consequently pressure on time series backend) can be reduced significantly by putting a rate limit on tags processed in data-service layer.