Deprecate Stream-related API

[jyemin]

Adds:

• TransportSettings abstract class
• NettyTransportSettings subclass of TransportSettings
• A new method on MongoClientSettings to configure TransportSettings

Deprecates:

• MongoClientSettings#streamFactoryFactory
• NettyStreamFactoryFactory
• NettyStreamFactory
• AsynchronousSocketChannelStreamFactory
• AsynchronousSocketChannelStreamFactoryFactory
• BufferProvider
• SocketStreamFactory
• Stream
• StreamFactory
• StreamFactoryFactory
• TlsChannelStreamFactoryFactory

JAVA-5051

[jyemin]

Couple of things:

Though JEP 211 indicates that it should be otherwise, and my testing directly with javac confirms the expected behavior, when building the driver I'm getting warnings about imports of classes/interfaces that have been deprecated. I'm not sure why, or what to do about it. Options:

1. Fully qualify all references to deprecated types so that the imports can be removed
2. Disable linting for deprecation
3. Live with the warnings until it's time to remove the deprecated types for 5.0

Scala test The_scala_package_should_mirror_parts_of_com.mongodb.connection_in_org.mongdb.scala.connection is passing by adding exceptions for the two new classes. Not sure whether to add Scala wrappers for them instead.

[jyemin]

I still like this name... at least better than IoSettings. Note that Netty refers to its implementation as "Transport Services".

An alternative that keeps the same spirit would be something like TransportImplementationSettings.

[jyemin]

Going once...

[stIncMale]

I am good with the name.

[stIncMale]

When I run ./gradlew clean check jar scalaCheck kotlinCheck testClasses docs -x test -x integrationTest -x spotlessApply with javac 17.0.3, I am still getting lots of warnings. Here is an example:

Task :driver-core:compileJava
/Users/valentin.kovalenko/Documents/projects/mongo-java-driver/driver-core/src/main/com/mongodb/MongoClientSettings.java:29: warning: [deprecation] StreamFactoryFactory in com.mongodb.connection has been deprecated
import com.mongodb.connection.StreamFactoryFactory;

[jyemin]

I am still getting lots of warnings.

Yes, I mentioned that here, and gave several options for how to proceed.

[stIncMale]

Yes, I mentioned that #1195 (review), and gave several options for how to proceed.

Sorry, I thought the added @SuppressWarnings("deprecation") were supposed to solve that. I like "2. Disable linting for deprecation combined with modified 3: live without the lint until it's time to remove the deprecated types for 5.0 (we'll move the program elements into the internal package, remove @Deprecated from them, enable the lint back again).

[jyemin]

I went with option 2 and disabled linting for deprecation

[stIncMale]

A few more suppressions are needed, as there are still some warnings (or, rather notes). Here is an example:

Task :driver-sync:compileJava
Note: /Users/valentin.kovalenko/Documents/projects/mongo-java-driver/driver-sync/src/main/com/mongodb/client/internal/MongoClientImpl.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

[stIncMale]

No, I was wrong. AbstractUnifiedTest already specifies @SuppressWarnings("deprecation") at the class level, and the note is still there. I guess, it's supposed to be like that.

[jyemin]

I guess, it's supposed to be like that.

I'm mystified by the behavior of the compiler in this regard.

[rozza]

LGTM - So whats next after this PR?

As internally we continue to use StreamFactoryFactory is there a ticket for the replacements? I'm interested in what the alternative will look like.

[jyemin]

So whats next after this PR?

Similar to what we did with the Operation layer in 3.x. We'll remove the two deprecated methods on MongoClientSettings, and then move all thee deprecated types to com.mongodb.internal.connection. After that we can see if we want to refactor anything. One obvious thing is to get rid of StreamFactoryFactory and just use StreamFactory directly. Another is to get rid of Stream#supportsAdditionalTimeout as that was added only due to Stream being a public type. We'll also need to deal with the removal of ServerAddress#getSocketAddress, which we can do once Stream is no longer public. There may be other simplifications, but these are the ones I'm aware of.

The point of deprecation/removal here is not that this is not a useful abstraction for the driver. It's that it doesn't need to be part of the driver API, as afaik no-one has ever needed to create their own implementation of StreamFactoryFactory and having these types as as part of the API makes it hard to refactor and evolve the driver.