Use packaging.metadata to parse and validate upload metadata

[dstufft]

This is the first piece of #14716 that has been split out.

It is currently blocked on pypa/packaging#733 and pypa/packaging#735 pypa/packaging#755.

This removes (most) of the metadata handling from the MetadataForm, and instead uses the packaging.metadata module to interpret and validate the metadata (other than our custom validations we add on top of the standard validations).

The MetadataForm is now the UploadForm, and it has been drastically stripped down to include only the name, version, and the non metadata pieces of information (filetype, filename, etc).

This PR should make our metadata validation more strict than it currently is, with no regression due to:

• The packaging.metadata library tracks what version of the metadata a field was added, and makes it an error to use that field on older metadata versions.
• Any validations that we previously had, that packaging.metadata didn't already handle, have been layered on top of the built in validations.

The main place this isn't true, is we no longer attempt to validate "legacy" specifiers like requires, provides, obsoletes, and requires-external, and we just allow them to be free form strings.

The UploadForm continues to support fetching the name and version of the upload. This PR itself doesn't actually require that functionality, as we could just use the Metadata object for everything, but future PRs will want to access the name/version before the Metadata object has been created, so we leave them there to make that transition easier.

We do add sanity checks to make sure that the name and version from the UploadForm are equivalent to the name and version from the Metadata, which again is kind of silly currently, but will be more important in a later PR. ¹

Looking at the updated tests in the test_legacy.py file should give a good indication about the user visible changes, for the most part the tests largely just worked, and the changes needed to make them work were primarily adjusting the error messages or fixing test data that was actually invalid but the old validation routines allowed it.

Footnotes

1. Removed because it was impossible to test until the future work that makes this actually possible to happen. ↩

[miketheman]

Initial review note: It's not simple to identify the changes made, since there's two operations done in the main commit - moving functions to new modules, and then changes to those functions to adopt the new pattern.
If those pieces were distinct, it'd make identifying what's changed after the code was moved around much easier.

[di]

Currently blocked on a 24.0 release of pypa/packaging: pypa/packaging#755

[hugovk]

Currently blocked on a 24.0 release of pypa/packaging: pypa/packaging#755

packaging 24.0 has been released: https://pypi.org/project/packaging/24.0/

[di]

I think this is ready to merge @dstufft, can you review my edits?

[dstufft]

The edits look 💯 to me! Thanks for taking this across the finish line.

[asottile-sentry]

this appears to regress some metadata validation:

twine: 25hWARNING  Error during upload. Retry with the --verbose option for more details. 
twine: ERROR    HTTPError: 400 Bad Request from https://upload.pypi.org/legacy/        
twine:          'description-content-type' must be one of ['text/plain',               
twine:          'text/markdown', 'text/x-rst'], not ''. See                            
twine:          https://packaging.python.org/specifications/core-metadata for more     
twine:          information.                                                           
twine: