Feat: migrate couchbase client2 to client3

[laglangyue]

Motivation and backword

#400

The Couchbase client2 has been deprecated for quite some time, and it's believed that many people are no longer using it. The usage of Couchbase client3 requires significant code modifications.
Changes between Couchbase client2 and Couchbase client3

(1) architecture and connection

• client2: cluster -> bucket -> document

• client3: cluster -> bucket -> scope -> collection -> document content (json, object, bytes, etc)
  Scope collection has default values, and scope is similar to a namespace.

• client2 requires session connection through bucket

Observable<AsyncBucket> openBucket(String name);

• client3 connects through the cluster

public static AsyncCluster connect(final String connectionString, final String username, final String password) {
return connect(connectionString, clusterOptions(PasswordAuthenticator.create(username, password)));
}

Referring to relational databases, such ad PG, client3's semantics are clearer. Cluster is the jdbc connection, bucket is the database, scope is the schema, and collection is the table.

(2) API

client2's API is designed with the observer pattern, making asynchronous API usage inconvenient.
client3 utilizes the CompletableFuture API from Java 8, making it easier to encapsulate as an asynchronous API.

Migration

(1) Connection

It's easy to do this. Cluster and bucket are mandatory parameters, while scope and collection are optional parameters. If not specified, it defaults to bucket.defaultScope and bucket.defaultCollection().

private[couchbase] def create(cluster: AsyncCluster, bucketName: String, scopeName: Option[String],
collectionName: Option[String]): CouchbaseSession = {
val bucket = cluster.bucket(bucketName)
val scope = scopeName.map(bucket.scope).getOrElse(bucket.defaultScope())
val collection = collectionName.map(scope.collection).getOrElse(bucket.defaultCollection())
new CouchbaseSessionImpl(cluster, bucket, scope, collection).asScala
}

(2) Inner API

● The original CouchbaseSession API had many overloads, which were mostly not used. I streamlined it, leaving only one API for each type of operation.
● Client3 uses the CompletableFuture API from Java 8, so I removed RxUtilities and then implemented javadsl.CouchbaseSession via CouchbaseSessionImpl. scaladsl.CouchbaseSession is achieved through an adapter.
● Regarding parameters and results, client3 defines various configurations and results. I directly used them in the inner API and provided methods to convert pekko settings to these APIs.

(3) Source/Flow/Sink API

I made as few changes as possible to the external API. Due to the lack of a document object, we need to provide an ID parameter. Currently, users provide a function to pekko for this.