catch unknown charset when decoding content-disposition params

[arshsmith1]

What do these changes do?

parse_content_disposition and content_disposition_filename decode RFC 5987 / 2231 extended parameters with unquote(value, encoding, "strict"), where the charset name comes straight from the (attacker-controlled) Content-Disposition header of a multipart part.

1. In parse_content_disposition the decode is wrapped in except UnicodeDecodeError, but an unknown charset name makes unquote raise the builtin LookupError, which slips past it. The bare name LookupError in this module is shadowed by payload.LookupError, so I reference builtins.LookupError to catch the real one.
2. content_disposition_filename runs the same decode on the reassembled continuation value with no guard at all, so both LookupError and UnicodeDecodeError propagate.

Reading part.filename / part.name on a crafted part then raises out of the parser. Both sites now give up the same way the existing UnicodeDecodeError branch already intended: the parameter is dropped, and no filename is returned.

Repro Content-Disposition: form-data; name="x"; filename*=unknown-8bit''foo: before, LookupError: unknown encoding: unknown-8bit; after, the parameter is ignored.

Are there changes in behavior for the user?

Only for malformed input: an extended-parameter filename with an unknown charset, or undecodable bytes in the continuation form, is ignored instead of raising. Valid values are unchanged.

Is it a substantial burden for the maintainers to support this?

No. It extends the existing exception handling by a few lines and adds unit tests next to the sibling cases.

Related issue number

N/A

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes (N/A, internal parser behavior, no public API change)
• If you provide code modification, please add yourself to CONTRIBUTORS.txt
• Add a new news fragment into the CHANGES/ folder