feat(tron): initial tron HD activation support

[laruh]

This pull request introduces initial support for the TRON (TRX) coin activation, targeting HD mode.
coin configuration for coins file:

{
  "coin": "TRX",
  "name": "TRON",
  "fname": "tron",
  "rpcport": 80,
  "mm2": 1,
  "sign_message_prefix": "Tron Signed Message:\n",
  "required_confirmations": 3,
  "avg_blocktime": 3,
  "protocol": {
    "type": "TRX",
    "protocol_data": {
      "network": "Mainnet"
    }
  },
  "derivation_path": "m/44'/195'"
}

To test fucntionaity

Set "enable_hd": true in the KDF configuration.
Use the enable_eth_with_tokens request with "TRX" as the ticker.

curl --url "http://127.0.0.1:7783" --data '{
  "userpass": "Zafr2xa9w!",
  "method": "enable_eth_with_tokens",
  "mmrpc": "2.0",
  "params": {
    "ticker": "TRX",
    "mm2": 1,
    "swap_contract_address": "0xf9000589c66Df3573645B59c10aa87594Edc318F",
    "swap_v2_contracts":{
	    "maker_swap_v2_contract": "0xf9000589c66Df3573645B59c10aa87594Edc318F",
	    "taker_swap_v2_contract": "0x7Cc9F2c1c3B797D09B9d1CCd7FDcD2539a4b3874",
	    "nft_maker_swap_v2_contract": "0xf9000589c66Df3573645B59c10aa87594Edc318F"
    },    
    "fallback_swap_contract": "0xf9000589c66Df3573645B59c10aa87594Edc318F",
    "nodes": [
      {
        "url": "https://ethereum-sepolia-rpc.publicnode.com"
      }
    ],
    "erc20_tokens_requests": []
  }
}'

However, one thing in the HD activation response concerns me. I decided to reuse EthCoin for TRON support (since the keypair is fully compatible), but the HDAddress type for EthCoin is defined as pub type EthHDAddress = HDAddress<Address, Public>;, which uses the Ethereum address format. As a result, the address shown in the activation response appears in Ethereum format.

https://github.com/KomodoPlatform/komodo-defi-framework/blob/63043f3915f80977c0b287dfeaa0b66749902885/mm2src/coins/coin_balance.rs#L581-L588

Note: In the logs, I can see that the correct TRON address is generated from the seed (checked address with other crypto wallet which supports bip-32/39 and Tron), so the key derivation itself works as expected.

26 04:48:36, coins::coin_balance::common_impl:574] INFO Generate '1' addresses: ticker=TRX account_id=0, chain=External
26 04:48:36, coins::eth:4535] WARN Using stub implementation for Tron address_balance for Address(TSfGxqREWhugXUSdt6NtY6Q5NN9T8xZ9tC / 0x41b715f5425e3e9d68774ee3f5eb232cf756e58b8b), returning 0 SUN

---

Address Compatibility Note

In the pr I dont enforce strict TRON-specific address format for swap addresses.
This is because TRON and Ethereum addresses are fully compatible at the byte level:

• Ethereum addresses are the last 20 bytes of the Keccak-256 hash of the public key (H160), typically represented in hexadecimal format with a 0x prefix.
• TRON addresses use the same 20-byte public key hash, prefixed with 0x41, and then encoded in Base58Check for display.

Essentially:

• An Ethereum address is: H160
• A TRON address is: 0x41 + H160 (Base58Check encoded for display)

This means the underlying data (H160) is the same, and TRON addresses can be derived from the same key pair as Ethereum.

However, I agree that we should enforce TRON-specific address format later in requests, to align with user expectations and network standards.

[onur-ozkan]

What I realized while reviewing this PR is that we are adding a lot of TODOs to the codebase. It's probably much better to create a tracking issue for them instead.

[mariocynicys]

Thanks!
first iteration

[onur-ozkan]

LGTM, thank you.

[dimxy]

Maybe this is not directly related to this PR,
but we have the ProtocolNotSupported error variant and at the same time a text description attached, which means the same. We could refactor such variants like that:

#[display(fmt = "Protocol {} not supported", _0)]  // Such an attribute could be added for RPC-level errors
ProtocolNotSupported { protocol: String }

[dimxy]

Here instead of BalanceError::Internal we could use a dedicated variant BalanceError::ProtocolNotSupported, like in other errors

[laruh]

Its better to revise error variants in other pr

[dimxy]

I have few questions:

• in the curl sample in the PR description the "mm2": 1 param is not needed, right?
• in the same curl sample we enable TRX coin with a sepolia node. I think this is not very good and should be prevented by the API. Better to create an issue to add code that ensures that nodes from the appropriate network are used for the coin to be enabled.

[laruh]

in the curl sample in the PR description the "mm2": 1 param is not needed, right?

This pr is not merged yet #2450

in the same curl sample we enable TRX coin with a sepolia node. I think this is not very good and should be prevented by the API. Better to create an issue to add code that ensures that nodes from the appropriate network are used for the coin to be enabled.

You are asking for TronClient support. It is in the plans. The node in the request is just a string with the komodo proxy flag (the array of nodes to be clear). For the Tron client, this request object should also be used to construct the transport layer. Since the current PR does not aim to provide full TronClient support, we are only allowing the code to build the Web3 instance for now.

[laruh]

I will update tron checklist #1542 (comment)
upd: done

[mariocynicys]

don't we wanna do such a check in most places since we now merged CoinType::Eth into CoinType::TRX?