chore: disable store protocol by default

[jm-clius]

Opening this suggestion as a PR, because I believe it should be done before the release if we agree upon it.

Disables store protocol by default.

Reasoning

One of the most important considerations for configuration is to have good defaults. I believe the default for store (which now implies actually persisting historical messages) should be false:

• the 95% use case for running a nwaku node is "run a relay-only node" - this should be the reasonable default
• this use case should not preclude such nodes from querying store nodes as a client. This is now always the case, even with store disabled.
• previously persisting messages would have been disabled by default (via the now deprecated persist-messages option)
• operators who upgrade their relay nodes and previously didn't care about or configure store will now suddenly start storing messages unless they change their config, especially a problem for those on resource-restricted devices.

TL;DR

To work as it did before store should now by default be false. I think this is the most reasonable default use case. :D

[status-im-auto]

Jenkins Builds

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
✔️	922e663	#1	2022-11-11 15:20:59	~16 min	linux	📦bin
❌	922e663	#1	2022-11-11 15:21:05	~16 min	macos	📄log
✔️	922e663	#2	2022-11-12 11:49:58	~13 min	macos	📦bin
✔️	d749331	#3	2022-11-14 08:09:45	~13 min	macos	📦bin
✔️	d749331	#2	2022-11-14 08:10:53	~15 min	linux	📦bin

[LNSD]

LGTM ✅

[LNSD]

Do we explicitly set the store parameter to true in our fleet? We are good to merge this if we are explicitly specifying the store flag in the configuration, otherwise, we need to set it before merging.

[rymnc]

LGTM, and as @LNSD mentioned, we should probably loop in @jakubgs as well

[alrevuelta]

lgtm. Side comment, having a networkmonitor tool helps when making this kind of changes, since it allows us to measure the impact of this (i.e. decrease in number of peers providing store capability).

[jm-clius]

Side comment, having a networkmonitor tool helps when making this kind of changes, since it allows us to measure the impact of this (i.e. decrease in number of peers providing store capability).

@alrevuelta good point. Will be interesting to see the results. From the already published results I think the number of store nodes will go down considerably, as we'll only be listing actual history-storing nodes from now on.

Do we explicitly set the store parameter to true in our fleet?

Luckily we do: cc @LNSD @rymnc

• Role: https://github.com/status-im/infra-role-nim-waku/blob/master/templates/docker-compose.yml.j2#L42-L43
• Status fleets: https://github.com/status-im/infra-status/blob/master/ansible/group_vars/status.yml#L10
• Waku fleets:
  https://github.com/status-im/infra-nim-waku/blob/master/ansible/group_vars/wakuv2-prod.yml#L10
  https://github.com/status-im/infra-nim-waku/blob/master/ansible/group_vars/wakuv2-test.yml#L14