fix: allow deserializing UiAccount rent epoch > u64

[jordy25519]

Problem

allows deserializing larger max rent epoch values

closes #2950

Summary of Changes

deserialize rent epoch as u128 before clamping to u64::MAX

[jordy25519]

I'd also like to back port this fix to 1.16.* crates if possible

[buffalojoec]

Sorry @jordy25519 but what exactly is the motivation here? Everywhere in the source, rent_epoch is a u64. Also, we can't backport to 1.16. The oldest branch we could backport to would be 2.0, and you'd have to make a case for the backport.

EDIT: Oops, maybe I should read the linked issue. I'm still curious where that value comes from, though? It's 385 above u64::MAX.

[jordy25519]

not sure right channel to broadcast to RPC providers and get this fixed as it shouldn't happen.
I assumed some intermediate infra is re-serializing the value incorrectly.
haven't seen the issue with rpcpool or helius, and given most clients are using Ts anyway the issue seems to have gone unnoticed for the most part.

for completeness, more examples:

• C# client issue: [Bug]rentEpoc > ulong.MaxValue magicblock-labs/Solana.Unity-Core#49
• blog post from RPC provider with bad value used in all getAccountInfo examples: https://blog.syndica.io/understanding-solana-rpc-a-comprehensive-guide-for-developers/
• bad response from getblock.io (retrieved via curl)

{
  "id": 1,
  "jsonrpc": "2.0",
  "result": {
    "context": {
      "apiVersion": "1.18.22",
      "slot": 290645650
    },
    "value": {
      "data": [
        "KLUv/SAAAQAA",
        "base64+zstd"
      ],
      "executable": false,
      "lamports": 2088540689624,
      "owner": "11111111111111111111111111111111",
      "rentEpoch": 18446744073709552000,
      "space": 0
    }
  }
}

[jordy25519]

accidentally closed