[corechecks] Support custom tags in every corechecks

[remeh]

What does this PR do?

This PR unify the use of custom tags in corechecks configuration files.
Some corechecks were correctly using the tags field of their configuration file, but they did it manually, some others corechecks were completely ignoring it.

Motivation

Be consistent with the work done by agent-integrations which made sure that the tags configuration field is correctly used.

Additional Notes

While a check is running CheckBase.CommonConfigure(...), if the tags configuration field is set, those tags are stored into the sender used by the current check, copying the behavior of the fields min_collection_interval and empty_default_hostname.
Thus, when the sender is used to send a metric, an event or a service check, it appends the custom tags to the message.

I've chosen this solution mainly for those pros:

• the checks developer can't forget them while sending metrics, etc.
• the next check using CheckBase won't need to manually deal with the tags configuration field
• no flag to set on checks or anything in the code by the developer. The sole presence of tags inside the corechecks configuration activate this behavior.

But it has cons:

• it's kind of implicit for the developer of new corechecks, which is something I tend to dislike. But this is this implicit part which avoids the developer to forget to add custom tags while sending metrics, events, etc
• the checkSender is responsible for storing the custom tags, which is ok, but not ideal.
• I had to remove code from the checks which were manually dealing with custom tags, same goes for some of their unit/integration tests, making this PR more verbose.

Some design choices:

• the check doesn't have access to its custom tags → avoid the mistake of adding them again while sending metrics, etc.

[codecov-io]

Codecov Report

Merging #2723 into master will increase coverage by 0.03%.
The diff coverage is 45.61%.

@@            Coverage Diff             @@
##           master    #2723      +/-   ##
==========================================
+ Coverage    57.4%   57.44%   +0.03%     
==========================================
  Files         392      393       +1     
  Lines       25616    25765     +149     
==========================================
+ Hits        14705    14800      +95     
- Misses       9943     9988      +45     
- Partials      968      977       +9

Impacted Files	Coverage Δ
pkg/collector/corechecks/system/disk.go	68.83% <ø> (+3.77%)	⬆️
pkg/collector/corechecks/containers/cri.go	27.9% <ø> (-1.64%)	⬇️
...g/collector/corechecks/containers/docker_events.go	68.75% <ø> (+0.56%)	⬆️
pkg/autodiscovery/integration/config.go	55.03% <ø> (ø)	⬆️
pkg/collector/corechecks/containers/docker.go	6.04% <0%> (+0.02%)	⬆️
pkg/aggregator/mocksender/mocked_methods.go	14.81% <0%> (-1.19%)	⬇️
pkg/collector/corechecks/checkbase.go	32.83% <0%> (-3.84%)	⬇️
pkg/aggregator/mocksender/mocksender.go	93.54% <100%> (+0.21%)	⬆️
pkg/collector/corechecks/net/network.go	49.23% <100%> (-0.77%)	⬇️
pkg/collector/corechecks/system/disk_nix.go	73.01% <100%> (-1.23%)	⬇️
... and 10 more

[remeh]

Keeping this attribute only because it's used by the legacy converter is not great. But for now, I've no good solution except this comment to avoid somebody to use this field.

[xvello]

If you want to be bullet-proof, you can use anonymous embedding to create a new type extending DockerConfig, in the legacy package:

type fullDockerConfig struct {
    containers.DockerConfig
    Tags                     []string           `yaml:"tags"`
}

But your approach is OK

[hush-hush]

👍

[xvello]

If you want to be bullet-proof, you can use anonymous embedding to create a new type extending DockerConfig, in the legacy package:

type fullDockerConfig struct {
    containers.DockerConfig
    Tags                     []string           `yaml:"tags"`
}

But your approach is OK

[xvello]

LGTM, please get a review from croissant too