feat(statusd)_: websocket endpoint for getting events

[igor-sirotin]

Closes #5803

Description

This PR enables to get status-go events through a Websocket endpoint.

Usage

1. Run like this: statusd --server=localhost:12345.
2. Connect with any websocket client to ws://localhost:12345

Response structure

1. Response will be a TextMessage.
2. The signal structure can be found here
   

   status-go/signal/signals.go

   Lines 30 to 33 in c9b777a

   	type Envelope struct {
   	Type string `json:"type"`
   	Event interface{} `json:"event"`
   	}

   
   ... which is:

   {
       "type": "<event-type>",
       "event": {}, // event-specific properties here
   }

Events

Possible events are described in ./signals directory. Events are grouped by some logic:

For example, here's the events_community_reevaluation.go

It defines 1 signal: community.memberReevaluationStatus. It will be set as type of event in the signal.

status-go/signal/events_community_reevaluation.go

Lines 3 to 5 in 5f4aab3

	const (
	MemberReevaluationStatus = "community.memberReevaluationStatus"
	)

With this event structure:

status-go/signal/events_community_reevaluation.go

Lines 15 to 18 in 5f4aab3

	type CommunityMemberReevaluationSignal struct {
	CommunityID string `json:"communityId"`
	Status ReevaluationStatus `json:"status"`
	}

[status-im-auto]

Jenkins Builds

Click to see older builds (10)

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
✔️	f43b885	#1	2024-09-06 17:17:51	~2 min	tests-rpc	📄log
✖️	f43b885	#1	2024-09-06 17:18:03	~2 min	tests	📄log
✔️	f43b885	#1	2024-09-06 17:19:29	~4 min	linux	📦zip
✔️	f43b885	#1	2024-09-06 17:20:18	~5 min	ios	📦zip
✔️	f43b885	#1	2024-09-06 17:20:47	~5 min	android	📦aar
✔️	a830f8b	#2	2024-09-06 22:40:01	~1 min	android	📦aar
✔️	a830f8b	#2	2024-09-06 22:40:36	~2 min	linux	📦zip
✔️	a830f8b	#2	2024-09-06 22:40:44	~2 min	tests-rpc	📄log
✔️	a830f8b	#2	2024-09-06 22:43:38	~5 min	ios	📦zip
✔️	a830f8b	#2	2024-09-06 23:09:48	~31 min	tests	📄log

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
✖️	e3c4edd	#3	2024-09-12 12:21:17	~1 min	tests	📄log
✔️	e3c4edd	#3	2024-09-12 12:21:57	~2 min	tests-rpc	📄log
✔️	e3c4edd	#3	2024-09-12 12:23:19	~3 min	ios	📦zip
✔️	e3c4edd	#3	2024-09-12 12:23:24	~3 min	linux	📦zip
✔️	e3c4edd	#3	2024-09-12 12:24:06	~4 min	android	📦aar
✔️	1d3c18a	#4	2024-09-12 13:01:33	~1 min	android	📦aar
✔️	1d3c18a	#4	2024-09-12 13:02:05	~2 min	linux	📦zip
✔️	1d3c18a	#4	2024-09-12 13:02:15	~2 min	tests-rpc	📄log
✔️	1d3c18a	#4	2024-09-12 13:03:12	~3 min	ios	📦zip
✔️	1d3c18a	#4	2024-09-12 13:31:15	~31 min	tests	📄log

[igor-sirotin]

I should probably rename SignalsServer to something more generic.

Thinking of this, something came up to my mind.
There's one more thing that statusd doesn't enable to test: mobile/status.go API.

---

This comment was converted to a ticket:

• Enable calling mobile/status.go API with an HTTP endpoint in statusd #5828

---

cc @antdanchenko @anastasiyaig @churik, would something like this help you with testing on status-go level?
We can have a chat and I'll show you more details if needed.

[anastasiyaig]

@igor-sirotin i love the fact i can use web sockets, thats amazing:) i would appreciate a call with you to go through all this together 🙏
i think @glitchminer is also interested

[osmaczko]

Nice and clean!

[osmaczko]

Thinking of this, something came up to my mind.
There's one more thing that statusd doesn't enable to test: mobile/status.go API.

Good point.

Proposal

1. Reuse this SignalsServer to enable functional testing of mobile/status.go API.
   Add api/restore-account-and-login kind of endpoints.
2. Remove from statusd all logic of creating/restoring accounts.
   Just set up the SignalsServer to provide a full status-go API with HTTP.
3. Remove CLI arguments like --seed-phrase, --password, --config, etc.
   Instead, use RestoreAccountAndLogin and pass desired configuration with it.

Maybe instead having two separate servers and many endpoints for mobile/status.go API we could have one server which will both handle mobile/status.go calls and proxy to RPC server spawn by GethBackend.

I like the idea in general, but I would be cautious with clients of statusd. I'm not sure if it would be feasible to shift the responsibility of account creation, restoration, etc., for all clients. For instance, see: Mailserver README and Bootnode README, although I'm not certain whether either of these is still relevant.