Sorry I squeezed the fixes for #17 #19 and a base64+zstd fix into the same PR.

The first commit in the PR fixes the following problem. The jsonParsed encoding won't work if the account data can be parsed by the RPC node. For example, the spl-token account will be actually parsed! The notification from WS becomes

{
    "jsonrpc": "2.0",
    "method": "accountNotification",
    "params": {
        "result": {
            "context": {
                "slot": 114915064
            },
            "value": {
                "lamports": 2039280,
                "data": {
                    "program": "spl-token",
                    "parsed": {
                        "info": {
                            "isNative": false,
                            "mint": "USDhTjkUXFfigLELiFpbBnpLmEm4aXHvdY2kDSadJDH",
                            "owner": "8dyR4YwFHzh2Pxmgs9TPst5Mu4kkES5tu8w6SuhdEyUG",
                            "state": "initialized",
                            "tokenAmount": {
                                "amount": "5771086231612606",
                                "decimals": 9,
                                "uiAmount": 5771086.231612606,
                                "uiAmountString": "5771086.231612606"
                            }
                        },
                        "type": "account"
                    },
                    "space": 165
                },
                "owner": "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA",
                "executable": false,
                "rentEpoch": 266
            }
        },
        "subscription": 10447
    }
}

and cannot be deserialized into the AccountRepresentation struct.

Choosing base64+zstd because it is compressed and should save network bandwidth theoretically (which is the bottleneck).

The rest two commits fixes #17 and #19.

Need it for this usecase:

let mut users = vec![];
shadow.for_each_account(|_, account| {
    if let Ok(user) = deserialize::<UserMetadata>(account) {
        if user.debt > 0 {
            users.push(user);
        }
    }
});

SolanaChangeListener::recv is used in https://github.com/hubbleprotocol/solana-shadow/blob/master/src/blockchain.rs#L225. However, SolanaChangeListener::recv is not cancellation safe means the internal state can be dropped unnoticed! e.g. When someone calls add_account and then during SolanaChangeListener's handling of the confirmation response and awaited in the middle, select! will cancel the half executed recv causes add_account to return AsyncWrap error.

Reconnecting every now and then might make the listener lose some updates. Maybe we can ping the RPC node every 5 secs to make the ws live?

One solution maybe use select! in the recv function of SolanaChangeListener and add a timer branch into select!.

While testing I noticed a stalling due to the connect_async hanging in the underlying tungstenite. src/stubborn implements a timeout and retry mechanism to ensure active reconnecting.

Quick Fix to test the Commitment level, changed default level from finalised. As such, if any consumers depend on the default to be finalised this will have to change.

Solana RPC endpoints automatically drop websocket connections when there is no activity for around 30 seconds. This change automatically reconnects to the Solana WS endpoint and recreates all subscriptions when the socket is closed for whatever reason.