chore: Optimize store

[Ivansete-status]

Description

We have three big-time consumption components in store:

1. database
2. communicate with database
3. return a response to store-client

This PR enhances the point 2, because we've been applying an incorrect async approach, which was to wait for a certain state with the following technique:

while pool.isBusy():
      await sleepAsync(0.milliseconds)

or

while not dataAvailable:
  await sleepAsync(timer.milliseconds(1))

Doing that has a very big impact on performance because we were adding a massive amount of future objects to the async queue. @arnetheduck - correct me if that statement is not accurate.

Therefore, in this PR we are starting to apply a better async approach to properly coordinate tasks.

---

Aside from that, we are simplifying pgasyncpool.nim and suggesting a better wrapper for the DbConn object.

---

We are also optimizing the following query so that we use the messages_lookup table instead:
SELECT timestamp FROM messages WHERE messageHash = $1

[github-actions]

This PR may contain changes to database schema of one of the drivers.

If you are introducing any changes to the schema, make sure the upgrade from the latest release to this change passes without any errors/issues.

Please make sure the label release-notes is added to make sure upgrade instructions properly highlight this change.

[github-actions]

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:3061

Built from 19af1f1

[gabrielmer]

LGTM, thanks so much!

Quick question - does doing

await sleepAsync(0.milliseconds)

pollute the pending Futures?

My understanding is that it gives control back to the event loop and the sleep's future is cleaned promptly, there shouldn't be more than one instance of the sleepAsync(0.milliseconds) in the pending Futures at once. But maybe I'm wrong

[Ivansete-status]

LGTM, thanks so much!

Quick question - does doing

await sleepAsync(0.milliseconds)

pollute the pending Futures?

My understanding is that it gives control back to the event loop and the sleep's future is cleaned promptly, there shouldn't be more than one instance of the sleepAsync(0.milliseconds) in the pending Futures at once. But maybe I'm wrong

Yes I understood it the same way but after some analysis, I got the impression that it doesn't work exactly that way

[NagyZoltanPeter]

LGTM! Great work!

[NagyZoltanPeter]

Just a hint, you may like it.
const SlowQueryThresholdInNanoSeconds = 1.seconds
... and use it if needed like...
SlowQueryThresholdInNanoSeconds.nanos()

I feel it more readable instead of counting the zeros :-)
WDYT would it work?

[Ivansete-status]

It's much better that way thanks! I've applied the suggestion in 54e635d