Provide a way to automatically delete multipart temporary files

[ikhoon]

Motivation:

Armeria does not automatically delete the uploaded files, so users should manually remove the temporary files themselves. It would be useful if we provided some options for how to delete multipart temporary files.

Related: #5652

Modifications:

• Add MultipartRemovalStrategy that is used to determine how to delete multipart files. For now, three options are supported.
  • NEVER
  • ON_RESPONSE_COMPLETION
  • ON_JVM_SHUTDOWN
• Add builder methods to server/virtualhost/service builders.

Breaking changes:

• Multipart temporary files are now automatically removed when a response is fully sent. If you want to keep the existing behavior, use MultipartRemovalStrategy.NEVER.

Result:

• You can now specify when to remove multipart temporary files using MultipartRemovalStrategy.

Server
  .builder()
  .multipartRemovalStrategy(MultipartRemovalStrategy.ON_RESPONSE_COMPLETION)

• Fixes #5652

[github-actions[bot]]

🔍 Build Scan® (commit: ec4abe209b2d7fb1d7474ea3b01fc53e5009fbc9)

Job name	Status	Build Scan®
build-windows-latest-jdk-21	✅	https://ge.armeria.dev/s/dja27ev646pb4
build-self-hosted-unsafe-jdk-8	✅	https://ge.armeria.dev/s/5nlo7kjvyinfw
build-self-hosted-unsafe-jdk-21-snapshot-blockhound	✅	https://ge.armeria.dev/s/62m6onluk2rg6
build-self-hosted-unsafe-jdk-17-min-java-17-coverage	✅	https://ge.armeria.dev/s/djzjtq5ebf7qa
build-self-hosted-unsafe-jdk-17-min-java-11	✅	https://ge.armeria.dev/s/jqxnkpfyj6xwe
build-self-hosted-unsafe-jdk-17-leak	✅	https://ge.armeria.dev/s/p4qoy6apzonqq
build-self-hosted-unsafe-jdk-11	✅	https://ge.armeria.dev/s/ilcigij56uggi
build-macos-12-jdk-21	✅	https://ge.armeria.dev/s/7ge2emykjysge

[jrhee17]

The build seems to be failing. Is this PR ready for review?

[ikhoon]

Fixed all failures. This PR is now ready for review.

[trustin]

There's still one test failure left.

[ikhoon]

I wonder if it is useful to synchronize the getters of VirtualHost and ServiceConfig. MultipartRemovalStrategy is used when there is a matching service. So ServiceConfig will always exist. VirtualHost.multipartRemovalStrategy() won't be used internally or by users.

Anyway, I fixed the failure.

[trustin]

ServiceConfig will always exist. VirtualHost.multipartRemovalStrategy() won't be used internally or by users.

A user could do this:

serverBuilder
  .withVirtualHost("foo.com")
    .multipartRemovalStrategy(NEVER)
    .service(...)
    .service(...);

Then virtual host level properties will be useful? If we have any service-level default, we should not do that, so that virtual host level (or default virtual host level if not set at virtual host level) is used when service level property is unset.

[minwoox]

Could you check the failure?

com.linecorp.armeria.internal.server.MultipartTempFileRemovalTest.[2] type=/default - 
org.opentest4j.AssertionFailedError: 
Expecting value to be false but was true
	at jdk.internal.reflect.GeneratedConstructorAccessor35.newInstance(Unknown Source)
	at [email protected]/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at [email protected]/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at app//com.linecorp.armeria.internal.server.MultipartTempFileRemovalTest.testRemovalStrategy(MultipartTempFileRemovalTest.java:79)
	at [email protected]/java.lang.reflect.Method.invoke(Method.java:568)
	at [email protected]/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
	```

[minwoox]

This isn't relevant to your PR but could you also fix this line? MultiPart -> Multipart https://github.com/line/armeria/blob/8bc6ca1e81ba32d77be76c30015228378d2eca5b/site/src/pages/docs/server-multipart.mdx#L66

[minwoox]

@ikhoon 👍 👍 👍