feat: add solana send endpoint

[NeOMakinG]

closes #1031

Description

Added the send endpoint logic:

• I decided to use the helius SDK because I feel like their custom endpoints will be typed this way, it will be easier for us to respect their types
• Like other chains, I assumed the TX is signed on client side

Testing

• You need to sign a TX

import { Transaction, SystemProgram, Connection, PublicKey } from '@solana/web3.js';

 ;(async () => const transaction = new Transaction().add(
    SystemProgram.transfer({
      fromPubkey: publicKey,
      toPubkey: publicKey,
      lamports: 100,
    })
  );
  transaction.feePayer = publicKey;

  const anyTransaction: any = transaction;
  anyTransaction.recentBlockhash = (await connection.getLatestBlockhash()).blockhash;
  
   try {
    const signedTransaction = await provider.signTransaction(transaction);
    console.log(Buffer.from(signedTransaction.serialize()).toString('base64'))
  } catch (error) {
    console.warn(error);
    throw new Error(error.message);
  }
)()

Then use this with the send endpoint (http://api.solana.localhost/api/v1/send)

Screenshots

Here is the TX:
https://solscan.io/tx/2yG59F1eughDiEg6R8FkcDe5MVSd2YYqiBeaH1AMX958nMXrLEpVPvgKpCDFwY2Doh6oM7NeHNdSbrcfSbckv8Ps

[kaladinlight]

A couple comments:

• Just to give context for the Service paradigm. The tsoa route registration does not support constructor ags. The service was a way to abstract shared logic between evm/utxo chains and pass args to the class for the specific endpoints/api keys. Seeing as this isn't really the case with solana and we could probably reduce the extra boilerplate and just implement the functions in controller.ts directly.
• We can use the helius sdk for now and agree it is necessary for typed responses from their api. Note that the connection is just an instance of @solana/web3.js connection and we could use web3 directly for rpc/subscription related things. May not be worth is the heluis sdk is more ergonomic to use though.

[NeOMakinG]

A couple comments:

• Just to give context for the Service paradigm. The tsoa route registration does not support constructor ags. The service was a way to abstract shared logic between evm/utxo chains and pass args to the class for the specific endpoints/api keys. Seeing as this isn't really the case with solana and we could probably reduce the extra boilerplate and just implement the functions in controller.ts directly.
• We can use the helius sdk for now and agree it is necessary for typed responses from their api. Note that the connection is just an instance of @solana/web3.js connection and we could use web3 directly for rpc/subscription related things. May not be worth is the heluis sdk is more ergonomic to use though.

The helius sdk will be more ergonomic to use because of the in houses endpoints that are not usable with web3js