Avoid setting default Content-Type in content methods without explicit MediaType

[JiwonKKang]

Motivation:

• Risk of having duplicated content-type in response headers #5949

HttpResponse could generate duplicate Content-Type headers if a user manually added a Content-Type header after setting the content with content(String). This can cause client errors or unexpected behavior when parsing the response.

Modifications:

• Updated the content methods without explicit MediaType in AbstractHttpMessageBuilder to avoid automatically setting the Content-Type header.
• Added a new content(HttpData) method to HttpMessageSetters that allows setting content without adding any headers by default.
• Adjusted test cases to ensure:
  • The Content-Type header is not automatically set when content(String) is used without MediaType.
  • No duplicate Content-Type headers are generated in response headers.

Result:

• The HttpResponse now avoids setting a default Content-Type header when content(String) is used, thereby reducing the risk of duplicate headers.

[github-actions]

🔍 Build Scan® (commit: c4676b1)

Job name	Status	Build Scan®
build-ubicloud-standard-8-jdk-8	✅	https://ge.armeria.dev/s/rcsasqs4qnofw
build-ubicloud-standard-8-jdk-21-snapshot-blockhound	✅	https://ge.armeria.dev/s/yxgx566jkmea2
build-ubicloud-standard-8-jdk-17-min-java-17-coverage	✅	https://ge.armeria.dev/s/v2hchjy5logz6
build-ubicloud-standard-8-jdk-17-min-java-11	✅	https://ge.armeria.dev/s/k2v3ysp3f3i2u
build-ubicloud-standard-8-jdk-17-leak	✅	https://ge.armeria.dev/s/qyvfvvbswkwag
build-ubicloud-standard-8-jdk-11	❌ (failure)	https://ge.armeria.dev/s/pbyvslgwx76kg
build-macos-12-jdk-21	✅	https://ge.armeria.dev/s/ultttwm6bpkjc

[jrhee17]

I don't think we can simply alter the behavior since it can result in breaking changes like seen in the tests.

Rather, I think a more reasonable approach would be:

1. Remember if a String content has been set for a request/response
2. At build time, if a content-type hasn't been set, set text/plain as the content-type

[trustin]

Agreed. Will you update the pull request, @JiwonKKang ?