The following Stapler / Jenkins core APIs are defined in terms of Commons FileUpload:

• StaplerRequest#getFileItem
• FilePath#copyFrom(FileItem)
• FileParameterValue(String, FileItem)
• FileParameterValue.FileItemImpl
• MultipartFormDataParser#getFileItem

Multipart file upload is built into the servlet spec since 3.1 via the HttpServletRequest#getPart() API, making the use of a third-party library unnecessary. Moreover, having third-party types in public API is a liability and constrains our ability to evolve Jenkins core. It would be better to remove our dependency on this library, since modern versions of the servlet API render it superfluous.

The abovementioned APIs have consumers in Stapler/core themselves as well as consumers in plugins. Recall that our integration guidelines state:

For new APIs and extension points, there is a link to at least one consumer.

Given that these APIs cross the core/plugin boundary, it would be ideal to have links to at least two consumers for each modified API: one core consumer and one plugin consumer. This is to validate that the API design is consumable from both core and plugins.

Based on the above reasoning, I suggest the following implementation strategy:

1. File draft pull requests to Stapler and Jenkins core completely removing Commons FileUpload, reimplementing any consumers in Stapler/core themselves in terms of the newer servlet APIs. For each change in API, find at least one plugin that is using it, and migrate that plugin as well. The purpose of this exercise isn't to come up with a mergable change, but rather it is to completely understand the problem space (forced by deleting Commons FileUpload in this exercise) and design an appropriate API that meets the needs of all consumers (forced by adapting core and at least one plugin, per API, in this exercise).
2. Once the above exercise has been completed, restore the Commons FileUpload APIs that were deleted in step 1 in the core/Stapler PRs, but marking them as deprecated in both the Javadoc and using the @Deprecated annotation. Then these PRs can be taken out of draft state and will become mergable, as they will now retain compatibility.
3. Ship the above two changes in a weekly release and an LTS release.
4. Go through any plugins that are still using the deprecated FileUpload-based Stapler/core APIs and migrate them to the new APIs introduced in Step 2.
5. Once a critical mass of such plugins has been released and adopted in BOM, remove the deprecated FileUpload-based APIs from Stapler/core.