[receiver/dockerstatsreceiver] Initial PR to onboard dockerstats onto mdatagen

[jamesmoessis]

First of all, apologies for the size of the PR. Thankfully, most of it is generated code/docs or mock/test data. Additionally, there is no change to the behaviour, since I haven't enabled the new implementation.

Description:
I wanted the initial PR to be backwards compatible with the existing implementation. So, I've re-implemented the scrape function as scrapeV2 (leaving the original) and testing them both alongside each other to ensure they produce the same metrics, and to give the reviewer confidence that feature parity is maintained. The bulk of the new implementation is all in receiver_v2.go.

I've defined the metrics to be recorded in metadata.yaml. With this, the new implementation (which isn't enabled yet) you can turn off and on each metric via the config, and all metrics have generated docs in documentation.md.

I've also fixed two bugs:

• When collecting data from multiple containers, it seems that the resource metrics aren't appended but overridden, so the last container to be collected is the only one that you see metrics for. I made a minor change to fix this.
• Specifying an HTTP endpoint (not unix socket) for the docker engine resulted in an incorrect dialer being used. It means it was ignoring the endpoint I specified and actually querying my local docker engine's unix socket. I had to make a minor change the to internal docker client to pass it an option, to make sure the correct dialer is being used.

Link to tracking Issue: #9794

Testing:
TestScrapes tests both implementations of scrape and ensures they emit the same metrics for the same datasource. I have mocked the docker engine using the HTTP test server.

Documentation:
mdatagen generates documentation in documentation.md.

Discussion points:
How should transition to using the new implementation by default? There are a few breaking changes that are needed to move the component forward here. With the two implementations, we could temporarily expose a config which allows users to stay on the "deprecated" implementation, giving them time to migrate, as we make the breaking changes to the new implementation of scrape only. Eventually, we delete the old implementation of scrape and a whole bunch of code with it. Would love thoughts and feedback here :)

[jamesmoessis]

Hello @rmfitzpatrick @MovieStoreGuy can you please review :)

[MovieStoreGuy]

There is just a few things I have comments on atm, I will come back to review this in further detail.

[jamesmoessis]

Going to document this here and link to the comment from the exclusion in go.mod.

There's a problem in v0.4.1 of go-connections/sockets.go where it overrides the proto and doesn't reset it when a new scheme is applied. This had the effect of making request to a unix socket even though an http endpoint was specified for the docker engine.

There are two possible solutions:

1. Pinning to 0.4.0 and excluding 0.4.1
2. Passing in a default dialer to via opts

For this PR, I think option (1) is better.

Edit: I've raised a bug to docker/go-connections: docker/go-connections#99

[mx-psi]

@jamesmoessis Note that, per the ref doc

exclude directives only apply in the main module’s go.mod file and are ignored in other modules

So we need to add this:

1. on the main go.mod file
2. on the contrib releases manifest

[jamesmoessis]

Thanks @mx-psi for pointing that out. I have updated the main go.mod. I can also raise another PR in the releases repo.

Before I do that, though, I would like to ask your opinion on whether this should be a replace or an exclude? Both seem to work:

replace github.com/docker/go-connections v0.4.1-0.20210727194412-58542c764a11 => github.com/docker/go-connections v0.4.0

or

exclude github.com/docker/go-connections v0.4.1-0.20210727194412-58542c764a

I'm thinking it's possibly better as a replace now that I've properly read those ref docs you linked.

[mx-psi]

@jamesmoessis I am not sure how exclude interacts with pseudoversions, so maybe a replace is indeed better.

[MovieStoreGuy]

I am happy with these changes, only nits that really shouldn't matter

[MovieStoreGuy]

If we have reverted the go-connections version, does this still need to happen?
Or is this just a safe nice to have?

[jamesmoessis]

Yeah, it doesn't need to be there anymore, but imo it doesn't hurt to leave it in, and it could be nice to have for future purposes or similar issues. I don't feel strongly either way

[jamesmoessis]

@rmfitzpatrick @mx-psi I believe I have addressed all comments, is there anything else I can do to move this PR forward?

[mx-psi]

Will wait for @rmfitzpatrick to give a final review

[rmfitzpatrick]

Thanks!

[mx-psi]

@jamesmoessis Regarding

How should transition to using the new implementation by default?

I would suggest using a feature gate for this

[jamesmoessis]

@mx-psi thankyou for the suggestion, I will implement in my next PR!