Migrate from legacy com.ning async-http-client to org.asynchttpclient

[jaredstehler]

Why

The multipart request builder depended on com.ning:async-http-client (1.9.x),
which has been EOL/unmaintained for years — upstream development moved to
org.asynchttpclient:async-http-client long ago. Keeping the Ning artifact pins
a stale, unsupported HTTP/Netty stack on the classpath and blocks dependency and
security updates that flow through basepom.

What

• Root pom: bumped basepom 68.1 → 69.3 and horizon 0.5.3 → 0.5.4, which
  brings in dependency management for the maintained org.asynchttpclient
  artifact and a consistent Netty version.
• slack-java-client pom: replaced com.ning:async-http-client with
  org.asynchttpclient:async-http-client, and declared io.netty:netty-buffer
  and io.netty:netty-codec-http directly since the new multipart API surfaces
  Netty types (ByteBuf, HttpHeaders) the builder now uses.
• MultipartHttpRequest: rewritten against the new API. Parts moved from
  com.ning.http.client.multipart.* to
  org.asynchttpclient.request.body.multipart.*. Part.setFileName(...) no
  longer exists, so file names are passed via the ByteArrayPart/FilePart
  constructors. Body bytes are produced by draining a
  MultipartUtils.newMultipartBody(...) MultipartBody into a ByteBuf.
• Removed TerminatingMultipartRequestEntity: it existed only to append the
  trailing MIME end-boundary that the old JDK provider omitted. The new
  MultipartUtils.generateMultipartParts already appends a
  MessageEndMultipartPart, making the workaround obsolete.

Notes

• The new FilePart constructor eagerly validates that the file exists and is
  readable (throws IllegalArgumentException), so a bad path now fails at
  build() time rather than at write time.
• The ...http.ning package name was left unchanged to avoid rippling import
  changes through SlackWebClient.

mvn clean verify passes across all modules.

🤖 Generated with Claude Code