refactor: Use base64 encoding for shell payload serialization

[coderabbitai]

Why

The current implementation in ProviderProxyService.connectToShell uses message.toString() to serialize Uint8Array shell payloads, which produces a comma-separated string format (e.g., "1,27,65"). While this works correctly with the current provider proxy expectations, base64 encoding would be a better choice for binary data because:

• More compact: Base64 is more space-efficient than comma-separated strings
• Standardized: Base64 is a well-established encoding for binary data in text formats
• Explicitly designed for binary data: Reduces ambiguity and potential edge cases
• Better compatibility: Standard encoding makes it easier to work with other tools and libraries

What

Update the shell payload serialization in both the frontend and provider proxy backend:

1. Frontend (apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts):

   • Change transformSentMessage in connectToShell method to encode the Uint8Array as base64 instead of using .toString()
   • Update the data field to contain the base64-encoded string

2. Backend (provider proxy):

   • Update the provider proxy to expect and decode base64-encoded payloads instead of comma-separated strings
   • Ensure backward compatibility if needed during the transition

References

• PR refactor: extracts logs/events/shell logic to service layer #2177: refactor: extracts logs/events/shell logic to service layer #2177
• Discussion: refactor: extracts logs/events/shell logic to service layer #2177 (comment)

Additional Context

The current code location:

transformSentMessage: message => {
  const remoteMessage: Record<string, unknown> = {
    type: "websocket",
    url,
    auth: providerCredentialsToApiCredentials(input.providerCredentials),
    chainNetwork: this.netConfig.mapped(input.chainNetwork),
    providerAddress: input.providerAddress
  };

  if (message.length > 0) {
    remoteMessage.data = message.toString(); // <-- Change to base64 encoding
  }

  return JSON.stringify(remoteMessage);
}

[stalniy]

@jzsfkzm would you like to work on this one?

[stalniy]

but just keep in mind that some people may use outdated version of frontend (cached in browser) and they still will send comma separated values, so provider-proxy needs to handle both formats. You can put a comment about this in the corresponding implementation that we need to remove it in a week

[jzsfkzm]

@jzsfkzm would you like to work on this one?

Sure, assign this to me please.