[receiver/elasticsearch]: add metrics for merge operations with total shard aggregation

[aboguszewski-sumo]

Description:
Three new metrics have been added. One was already present in metadata.yaml, but was not emitted.

Link to tracking Issue: #14635

Testing:
Unit and integration

Documentation:
Generated with mdatagen.

[djaglowski]

Would you mind splitting off a PR for the one that was mistakenly omitted? This is a bug and should be accepted separately.

The two new metrics seems reasonable to me.

[djaglowski]

Would you mind splitting off a PR for the one that was mistakenly omitted? This is a bug and should be accepted separately.

Nevermind. I missed that the metric was already be used. We're just adding another data point to it. Not a bug.

[aboguszewski-sumo]

I added the tests.

[aboguszewski-sumo]

@djaglowski I changed the metrics to disabled by default. There is one thing I've changed in the tests due to that. I decided that it would be the best if these metrics were enabled only in one test (I picked full because it seemed the most suitable one). There are two reasons for doing so:

1. This way we test the correctness of the metric, but also make sure that it is disabled by default.
2. Rebases will be much easier to be done. To be honest, the most annoying thing in working on these metrics is modifying the files with test results (and in case of this receiver, there are 5 files in total). If only one test file has to be modified with each PR, the rebases can go more smoothly.

I'd like to follow this convention for other metrics that are going to be disabled by default (I'll be fixing the PRs gradually), so if you have any objection, please raise it now.

Also, one small thing: the recently merged PR did not change the number of errors emitted (it should be 5 on main, not 4), so this is why this PR adds 3 metrics, but changes the number of errors by 4.

[djaglowski]

@aboguszewski-sumo, I agree with your reasoning on the test files. This should be a good pattern to follow going forward.