FutureSwap endpoints - deployment resiliency check

[fuxingloh]

As part of our workflow, it includes a resiliency check before deploying a new RPC via Ocean RPC Router. We will check the performance behavior of said endpoint complexity. This includes "down to the wire" and "computational" complexity.

https://github.com/DeFiCh/jellyfish/blob/a38e7f7cf50169d3fa1f7782071da0e062e27d56/apps/whale/src/module.api/rpc.controller.ts#L19-L21

1. "listpendingfutureswaps"

This RPC sends the entire "futureswap" waiting to execute over the wire without pagination - which doesn't scale well when there is an increased amount of future swap required to send over the wire.

2. "getpendingfutureswaps"

This RPC (also described in DeFiCh/ain#1202) isn't using a performant index structure for address lookup of futureswaps. It doesn't scale well when there is an increased amount of "futureswap". Once we release future swap on ocean infrastructure, we can expect an uptake un usage which might create a unhealthy feedback loop towards the index performance.

3. "lazy reward can't be used for FutureSwap"

Unrealized lazy rewards within "futureswap" can't be automatically realized when performing future swap. See DeFiCh/ain#1194

---

The alternative would be for the jellyfish ecosystem to index "FutureSwap" data. However, due to the sheer complexity of "gov var" that can trigger events within the FutureSwap, the amount of work required would be significant and put an extra load on our indexers to track consensus data. Similar to "Vault", it would only make sense for us to get the data out from defid directly. Or via an event stream with a pub/sub.

/triage accepted
/area packages
/priority important-soon