Simplify metadata generation flow, to be a lot more "linear"

[pradyunsg]

This PR takes a lot of steps, to inline InstallRequirement.prepare_metadata into SourceDistribution.prepare_distribution_metadata.

As described in #6607 (comment)

[pradyunsg]

I expect this to fail CI, since I'm 100% sure tests are directly using prepare_metadata.

[chrahunt]

This looks a bit more complicated to me because:

1. the metadata_directory is not something that we would want exposed externally - just the metadata
2. it more tightly couples the behavior of InstallRequirement to SourceDistribution

IMO a clearer approach would be to:

1. break up the arguments that we're passing to basic functions, like metadata_generator and get_metadata_generator, to reduce exposure of InstallRequirement and make them more reusable, or
2. pull out more functions that would serve as building blocks common to any way we decide to model installation/build (e.g. Centralize setuptools args construction #7175)

[pradyunsg]

I think I broadly agree with you.

The coupling of SourceDistribution and InstallRequirement was definitely something I didn't like while I was doing it but I did it anyway, since I ran outta time and filed the PR.

As for simplifying what actually gets passed into the operations.build functions, I agree. That's the intended follow up, among other things zcto this (i.e. once all the moving around of logic is settled).

A couple of things I'd appreciate inputs on:

• does 6d86c5f look like a good idea to you?
• would it make sense to skip the inlining of the logic into SourceDistribution (basically dropping d22a5fa)?

[chrahunt]

Yes and yes, IMO. I would even go so far as to inline generate_metadata where it is called in InstallRequirement and elevate _generate_metadata and _generate_metadata_legacy to non-module-private functions.

As a follow up if those are then refactored to take plain non-InstallRequirement arguments then they become very easy to test and understand.