[chore] Run make gogci

[crobert-1]

Description

Codewise, this PR is simply the result of running make gogci locally. I've also added it as a check on PRs in build-and-test to ensure it's been run by users, and added it to every make generate call to hopefully make it so developers don't need to manually run it.

[crobert-1]

This was originally added as part of #41759 to suppress linter warnings about the deprecated aws-sdk-go v1, but it looks like it's not needed and the other nolint directives are enough. Keeping this line gives lint errors, removing it allows the whitespace change below in this file.

[crobert-1]

Failing scope test looks to be unrelated to this PR, I've filed #45028

[braydonk]

A huge amount of files here are because of generated code from mdatagen. Should there be a PR that updates the templates to align with gci import orders?

[crobert-1]

Should there be a PR that updates the templates to align with gci import orders?

I think that's the ideal solution, I've filed open-telemetry/opentelemetry-collector#14306.

I will say though (with my very limited understanding of mdatagen) the logic in the templates could get considerably more complex just to save us from running a couple make commands (or making the one command after this PR, make generate, take longer than before). Every time files are generated, the imports would need to be fully understood by mdatagen and the templates. We'd end up with lots of checks saying "if this import block has imports that we'll need, an empty whitespace line should be here". It could end up adding an amount of noise and maintenance to keep that logic up to date perfectly for every template.

Edit: I just realized I can at least do a quick run through of files being changed here, and if any imports are out of order in mdatagen templates I can at least fix those. It won't be a 100% complete solution, but it at least can resolve some of these 👍

Edit 2: I did some more digging, I don't believe this is possible with current mdatagen functionality, given that import orders are not consistent across repos. Since mdatagen is in core, the core collector dependencies make up the third group of dependencies (the ones that are replace'd in go.mod. For example, the generated component test file for the otlphttp exporter. The core collector dependencies make up the third block of imports, and are replaced in go.mod. So core has these dependencies in the third block, contrib has them in the second. I'm not sure how mdatagen could properly account for these differences.