fix: reduced the SDK usage in batch 3 to stablize the batch

[quiet-node]

Description:
Initially, batch 3 frequently failed with the GrpcServiceError: gRPC service failed with status: TIMEOUT error. This occurred because batch 3 contained consecutive test cases that exhaustively utilized the SDK to retrieve and prepare for testing materials. This PR addresses the issue by reducing the SDK usage and delegating some tasks to the relay in batch 3. This prevents the exhaustive use of the SDK and thereby avoids the GrpcServiceError: gRPC service failed with status: TIMEOUT error.

Related issue(s):

Fixes #2568

Notes for reviewer:

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[sonarcloud]

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 SonarCloud

[github-actions]

Tests

    2 files  157 suites   14s ⏱️
854 tests 853 ✔️ 1 💤 0 ❌
866 runs  865 ✔️ 1 💤 0 ❌

Results for commit 910d476.

[github-actions]

Acceptance Tests

  16 files  209 suites   28m 29s ⏱️
603 tests 599 ✔️ 4 💤 0 ❌
640 runs  636 ✔️ 4 💤 0 ❌

Results for commit 910d476.

♻️ This comment has been updated with latest results.

[victor-yanev]

Nice change, I have also noticed the same happen in the API Batch 1 tests, so it would also be nice to apply this there.

I hope we have also brought this up to the SDK team? It looks like a very frustrating error which might make some users reconsider using the javascript SDK overall.

[quiet-node]

Nice change, I have also noticed the same happen in the API Batch 1 tests, so it would also be nice to apply this there.

I hope we have also brought this up to the SDK team? It looks like a very frustrating error which might make some users reconsider using the javascript SDK overall.

I have applied this same logic to batch 1 before and recently batch 1 seems pretty stablized. Please ping me when you catch batch 1 being flaky again.

regarding bringing this up to the SDK, I think the timeout makes sense and necessary. It's jsut because we exshaustively and repeatedly use the SDK, and test cases happen quite fast hence the timeout happened.