allow union of several retention policies

[Ivansete-status]

Description

• Fix the time retention logic. The logic could cause all the partitions to get removed because we checked if certain time threshold belongs to any partition. Instead, <-only approach is being used.
• Allow setting several retention policies simultaneously by a semicolon-separated string. For example: size: 50GB;time:86400. The node applies both and then, the most restrictive remains.

Validation done

I've validated that the proposed solution works well in waku.test.
By applying the following:

store-message-retention-policy = 'size:41GB;time:15724800'

... the database is kept up to the lowest retention policy threshold (either of them.)

In the following pic I share evidence how a retention policy is applied depending on which is more restrictive:

Related Issue

This PR aims to help mitigate the following issue as much as possible but it doesn't fixes it.

• bug: node gets completely blocked when DB overloaded #3764

[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.

[Ivansete-status]

The previous while implementation caused the deletion of all the partitions when using time retention policy.

[fcecin]

Isn't this oldestPartition.getLastMoment() < tsInSec?

That is, this whole partition is dead if the entire timestamp range in it is obsolete.

first = time 10
last = time 20
oldest msg we want = 15
we have to keep this partition, but first (10) < 15 and it gets deleted

(Maybe I'm just being dumb here, please check the math!)

[NagyZoltanPeter]

Yes, I have the same impression that it should be

Suggested change

	while oldestPartition.getFirstMoment() < tsInSec:
	while oldestPartition.getLastMoment() < tsInSec:

[Ivansete-status]

Good catch! Thank you both! You see that I'm nothing without a calculator xD
Addressed in fde1723

[fcecin]

I'm wondering whether we can't just delete this query inside method deleteMessagesOlderThanTimestamp*:

  (
    await s.writeConnPool.pgQuery(
      "DELETE FROM messages WHERE timestamp < " & $tsNanoSec
    )
  ).isOkOr:
    return err("error in deleteMessagesOlderThanTimestamp: " & $error)

Just dropping whole partitions is faster than running a query to collect the last expired messages inside the oldest partition (because, well, it's just less work). Maybe we can get away with some fuzziness in the time retention logic and just drop whole partitions at once? Sticking to data expiration in whole buckets is usually safer; it has a more predictable cost.

[fcecin]

Awesome!!
LGTM!

[NagyZoltanPeter]

Approve with the time check needs attention.

[igor-sirotin]

Can you please note what happens if duplicated options are found (I'd just fail to start in this case, as it's obviously a misconfiguration).

[Ivansete-status]

addressed in this 2eb14b6

[Ivansete-status]

I'm wondering whether we can't just delete this query inside method deleteMessagesOlderThanTimestamp*:
... ( I'm cutting to shorten the comment )

Yes good point. In this particular case, we are dropping partitions at the beginning of the proc.
For now I would leave it because that way the implementation is more accurate with the proc's name.
Thanks!