[PB-6281]: add encrypted file upload flow with multipart support

[terrerox]

• add bridge API methods/models for upload start, multipart finish, and file entry creation
• introduce encrypted uploader with SHA-256 part hashing and RIPEMD160 shard hash
• add upload token helpers in DocumentId and JSON parsing utilities
• add upload HTTP client config and Bouncy Castle RIPEMD160 dependency
• add crypto callback await helper and pending upload model

[TamaraFinogina]

Shouldn't it be the same string as in the SDK? https://github.com/internxt/sdk/blob/master/src/drive/storage/types.ts#L204

[terrerox]

Right, i missed that. Thanks!

[CandelR]

@terrerox After reviewing the upload implementation and taking another look at the download implementation, I have noticed that the entire module (EncryptedFileDownloader,EncryptedFileUploader, InternxtDocumentsProvider) relies on blocking threads:

• call.execute() blocks a thread for the duration of the transfer
• CompletableFuture.get() blocks another thread during encryption
• openExecutor exists solely to offload work from the binder thread, so it seems that waster a third thread. Opening a file ties up 3 threads, 2 of which do nothing but wait.

Migrating to coroutines solves this at the root:

• CryptoService is pure native Java, so it can be wrapped directly with suspendCancellableCoroutine
• call.execute() becomes call.await() via enqueue + suspendCancellableCoroutine
• All the AtomicReference + setOnCancelListener + OperationCanceledException wiring disappears, coroutine cancellation handles it automatically
• openExecutor can be removed entirely, runBlocking at the boundary of openDocument is the appropriate bridge

If you’d like to give this a go, it might be worth creating a ticket to address this issue before continue with iOS tasks, as coroutines are the standard concurrency model in modern Kotlin for Android and would significantly simplify the cancellation logic

[CandelR]

Try to use coroutines, Kotlin and the entire Android ecosystem have moved to coroutines as the standard async model.CompletableFuture.get() blocks the thread while waiting, coroutines suspend instead, freeing the thread for other work, and cancellation is automatic when the coroutine scope is cancelled . Replace with suspendCancellableCoroutine

[terrerox]

I will create another task to address this issue

[CandelR]

do not force the no nullable values (!!), this could lead in unexpected errors. Return the resutl to etag directly

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[terrerox]

@terrerox After reviewing the upload implementation and taking another look at the download implementation, I have noticed that the entire module (EncryptedFileDownloader,EncryptedFileUploader, InternxtDocumentsProvider) relies on blocking threads:

• call.execute() blocks a thread for the duration of the transfer
• CompletableFuture.get() blocks another thread during encryption
• openExecutor exists solely to offload work from the binder thread, so it seems that waster a third thread. Opening a file ties up 3 threads, 2 of which do nothing but wait.

Migrating to coroutines solves this at the root:

• CryptoService is pure native Java, so it can be wrapped directly with suspendCancellableCoroutine
• call.execute() becomes call.await() via enqueue + suspendCancellableCoroutine
• All the AtomicReference + setOnCancelListener + OperationCanceledException wiring disappears, coroutine cancellation handles it automatically
• openExecutor can be removed entirely, runBlocking at the boundary of openDocument is the appropriate bridge

If you’d like to give this a go, it might be worth creating a ticket to address this issue before continue with iOS tasks, as coroutines are the standard concurrency model in modern Kotlin for Android and would significantly simplify the cancellation logic

Implemented coroutines here