Fix/pool/info: fix the /api/pool/info

[sethdivyansh]

Resolves: #101

[sethdivyansh]

@Priceless-P Please review this PR.

[Priceless-P]

@sethdivyansh good catch
should be able to merge this when #90 is merged so that ci fixes will be checked. @jbesraa what do you think?

[jbesraa]

Thanks @sethdivyansh.
It feels redundant to me to get latency if we have a single address. Maybe the API endpoint should calculate latency rather than getting it from the router.

[sethdivyansh]

Thanks @sethdivyansh. It feels redundant to me to get latency if we have a single address. Maybe the API endpoint should calculate latency rather than getting it from the router.

I have moved the latency calculation to the API side. it’s now only computed when the /api/pool/info endpoint is called, as it is in the dashboard I am building, where it’s triggered via polling.
Let me know if this aligns with what you expected.

[Priceless-P]

@jbesraa I understand that it feels redundant when there’s only a single address, but having the API endpoint calculate latency would actually introduce more redundancy. The endpoint would still need to call the router internally to get the latency, since that’s where the function resides. This would also generate unnecessary logs on the pool side because it would involve connecting to the pool just to retrieve the latency. I think It's more efficient to get the latency directly at the point of connection, as we're currently doing