feat: connection health should be shard specific

[chaitanyaprem]

Problem

While going through the code debugging an issue, i had noticed that connection state is shown purely based on peer connections that are available. This would make sense when a single pubsubTopic is used, but with sharding and communities having their own shards/pubsubTopics or sharing shards, connection state or health should be shown per shard/pubsubTopic.

Towards this end i forsee following changes to be made:

1. Show peer connection health/status at community level (based on shard/pubsubTopic). e.g : in case of relay each shard/pubsubTopic should have enough healthy peers. Similar is the case with lightNode (i.e Filter and lightpush connections or peers should be available). Otherwise health/status should be shown as not good in community.
2. Wrt common pubsubTopic that would be used for 1:1 chats or group-chats, health or connection-status should be shown in the appropriate UI screen.

How this health/connection status has to be shown in status-desktop and mobile GUI is upto respective teams. Because this is specific to each community or shard.
Also, few points to keep in mind is how to indicate below scenarios such as :

• the common pubsubTopic (used by 1-1 and group chat) is unhealthy and community pubsubTopics are health
• 1-1 chat pubsubTopic is healthy, but common community pubsubTopic is unhealthy
• Few communities are unhealthy etc

Implementation

status-go shall not rely on individual peer connection or disconnection notification rather depend on peerConnHealth (which would just notify health status for a particular shard/pubsubTopic). We can consider 3 states for peerConnHealth:

• Minimally-Healthy(e.g: less than 4 peers are connected in relay-mode , 1 filter peer connection and 1 lightpush peer is available)
• Sufficiently-Healthy (e.g: min 4 peers are connected in relay-mode, more than 1 filter peer connection and atleast 2 lightpush peers available)
• UnHealthy (no peer connections are available in relay-mode, no filter or lightpush peers available in light-mode)

The following would indicate the peerConnHealth:

• - In Relay Mode: go-waku shall notify of this health
• - In lightMode: status-go shall derive it based on peer connections to Filter and lightpush(This shall be later migrated to SDK layer once Simplify FilterManager #4665 is complete)

Thoughts @richard-ramos @plopezlpz @kaichaosun @cammellos @vitvly

Note: More details regarding the approach on how reporting would be done shall be included as part of waku-org/go-waku#1021

Acceptance Criteria

TBD - once approach is finalized

[richard-ramos]

Yeah, this is an issue we have now regardless of which approach to follow with sharding. Ideally we should have separate banners of health indicators in the clients with one used for 1:1, group chats, communities with unassigned shards and unprotected shard for requests to join (shards 16/32 and 16/64); and then for each community that has an assigned shard, an specific health check for them.

[richard-ramos]

cc: @iurimatias as desktop changes would be needed too depending on solution proposals

[chaitanyaprem]

Relay mode connection health reporting is already addressed in waku-org/go-waku#1021