feat: integrates new lockService in sendRawTransaction

[konstantinabl]

Description

This PR integrates a new LockService into eth_sendRawTransaction to ensure proper nonce ordering for transactions from the same sender address. The service uses a per-address locking mechanism that prevents concurrent execution of transactions from the same account, thereby avoiding nonce-related race conditions.

• Modified sendRawTransaction to acquire a lock on the sender address before any async operations or side effects
• Lock is released in finally block to ensure cleanup on success or failure
• Feature controlled by USE_LOCK_SERVICE configuration flag

Related issue(s)

Fixes #4595

Testing

• Unit tests for sendRawTransaction with lock acquisition/release scenarios
• Unit tests for executeTransaction flow
• Tests cover success cases, error handling, and lock cleanup

Changes from original design (optional)

N/A

Additional work needed (optional)

N/A

Checklist

• I've assigned an assignee to this PR and related issue(s) (if applicable)
• I've assigned a label to this PR and related issue(s) (if applicable)
• I've assigned a milestone to this PR and related issue(s) (if applicable)
• I've updated documentation (code comments, README, etc. if applicable)
• I've done sufficient testing (unit, integration, etc.)

[github-actions]

Test Results

 20 files  +  7  272 suites  +104   22m 19s ⏱️ + 7m 50s
791 tests +251  787 ✅ +253  4 💤 ±0  0 ❌  - 2 
807 runs  +251  803 ✅ +253  4 💤 ±0  0 ❌  - 2 

Results for commit 3e754ec. ± Comparison against base commit e1a74b9.

♻️ This comment has been updated with latest results.

[codecov]

Codecov Report

❌ Patch coverage is 77.39726% with 66 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
.../src/lib/services/lockService/LocalLockStrategy.ts	57.41%	66 Missing ⚠️

@@                        Coverage Diff                        @@
##             feat/nonce-ordering-with-locks    #4627   +/-   ##
=================================================================
  Coverage                                  ?   94.23%           
=================================================================
  Files                                     ?      133           
  Lines                                     ?    21271           
  Branches                                  ?     1726           
=================================================================
  Hits                                      ?    20044           
  Misses                                    ?     1206           
  Partials                                  ?       21           

Flag	Coverage Δ
config-service	98.85% <100.00%> (?)
relay	90.71% <75.09%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...ckages/config-service/src/services/globalConfig.ts	100.00% <100.00%> (ø)
packages/relay/src/lib/clients/sdkClient.ts	96.01% <100.00%> (ø)
packages/relay/src/lib/eth.ts	99.57% <100.00%> (ø)
packages/relay/src/lib/relay.ts	98.65% <100.00%> (ø)
...thService/transactionService/TransactionService.ts	99.46% <100.00%> (ø)
.../relay/src/lib/services/hapiService/hapiService.ts	97.26% <100.00%> (ø)
...rc/lib/services/lockService/LockStrategyFactory.ts	100.00% <100.00%> (ø)
.../src/lib/services/lockService/LocalLockStrategy.ts	57.41% <57.41%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[quiet-node]

Releasing the lock here aligns perfectly with the design doc and works correctly, but it looks like it'd require changing method signatures, even their constructors, across multiple classes, HapiService, SdkClient methods, etc.

Instead, we can simply release the lock in the TransactionService.sendRawTransactionProcessor() method, like this:

// in TransactionService.sendRawTransactionProcessor()
...

const { txSubmitted, submittedTransactionId, error } = await this.submitTransaction(
  transactionBuffer,
  originalCallerAddress,
  networkGasPriceInWeiBars,
  requestDetails,
  lockSessionKey, // remove this
);

await this.lockService.releaseLock(...); // add release lock here

await this.transactionPoolService.removeTransaction(...);

...

From our previous discussion during the txPool implementation, we know TransactionService.submitTransaction() does not throw and instead returns any error. It also doesn’t perform any critical async work. So it should be safe to call releaseLock immediately after it returns.

This approach avoids passing sessionKey and lockService through HapiService and SdkClient.

This'd make the code cleaner, scoped within TransactionService class, while keeping the behavior exactly the same.

Let me know what you think.

[konstantinabl]

Yeah, i will move it, I was wondering if it would affect performance even with a little bit, currently the locks slow down significantly the process of sending a transaction but the difference is under 100ms so its fine. Will fix

[quiet-node]

Just as we did in the transaction pool implementation, would it make sense to abstract this feature-specific flag into its own service class?

In this case, ConfigService.get('ENABLE_NONCE_ORDERING') could be encapsulated within LockService, similar to how TransactionPoolService handles its flag.

[quiet-node]

nit: the comment above this line is misleading.

[konstantinabl]

fixed