optimize postgresql queries for API Server scanner

[OBorce]

• added a cache table for the latest delegation states so that we can efficiently retrieve all the latest data for each delegation of a pool
• added delegations balance in the pool endpoints

[ImplOfAnImpl]

The u8 is cryptic. In such a case it's better to at least leave a comment, e.g.

Result<Vec<(CoinOrTokenId, Amount, /*number of decimals*/ u8)>

(though rustfmt may not like such comments sometimes)

But since this tuple appears in public interfaces, it's better to make it a struct with named fields and use the struct everywhere.

P.S. it's also a bit strange that a vec is returned instead of a map with CoinOrTokenId as the key.

[OBorce]

replaced with DecimalAmount

[ImplOfAnImpl]

"ON CONFLICT (coin_or_token_id) DO NOTHING" IMO looks strange.

In the context of this particular function probably UPDATE would make more sense? I mean, what does set_fungible_token_issuance mean in the context of the storage - the token somehow got "re-issued", so probably we should just update the data.

In general, storage methods should make sense on their own. And same methods from the postgres and in-memory storage should probably behave in the same way.
And e.g. the in-memory storage makes no particular assumptions on when a token re-issuance can occur - it just adds a new issuance object for the provided token_id/block_height.
So I guess postgres should do the same, assuming that the same token can be issued multiple times at different heights. I.e. coin_or_token_decimals should have block_height as a part of the key and queries that use coin_or_token_decimals should take this into account.
But then the next question arises - why isn't token decimals value a part of ml.fungible_token? And the coin decimals never change, so there isn't much sense in putting them into the db. So coin_or_token_decimals seems redundant.

P.S. another weird thing about coin_or_token_decimals is that it's partially exposed from the storage interface via del_coin_or_token_decimals_above_height.
Where the in-memory storage implementation just does nothing.
IMO it's another sign that it should go.

[OBorce]

Removed the on conflict as a token can be issued only once, if there are multiple then it should be an error.

separated the set_fungible_token_issuance into 2 set_fungible_token_issuance and set_fungible_token_data, first for the initial issuance that can happen only once per token_id and the later for any modification to the token data from mint/change token authority ...

The new table is just a cache for faster lookups when updating address balances.

[ImplOfAnImpl]

Same comment.

And btw probably the above "INSERT INTO ml.nft_issuance" should also have "ON CONFLICT ... UPDATE" so that it behaves just like its in-memory counterpart.

[OBorce]

Doesn't have an on conflict because it cannot happen same as the insert of the nft above it.
Added a panic in the in-memory counterpart.