fix_: wakuv2 waitgroups

[igor-sirotin]

Problem

In nightly tests, there was a panic:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x17747a8]

goroutine 1180314 [running]:
github.com/status-im/status-go/wakuv2.(*Waku).processQueueLoop(0xc04ff7eb40)
	/home/jenkins/workspace/status-go/tests-nightly/wakuv2/waku.go:1416 +0xc8
created by github.com/status-im/status-go/wakuv2.(*Waku).Start in goroutine 1179373
	/home/jenkins/workspace/status-go/tests-nightly/wakuv2/waku.go:1146 +0x8d6

That's because there's a loop and we might access a nil w.ctx when stopping waku.

status-go/wakuv2/waku.go

Lines 1421 to 1428 in daa3695

	for {
	select {
	case <-w.ctx.Done():
	return
	case e := <-w.msgQueue:
	w.processMessage(e)
	}
	}

Fixes

1. I fixed the panic by adding a waitgroup to it.
2. Refactored the way we add to waitgroups, which should be done outside the goroutine (my mistake actually).

[status-im-auto]

Jenkins Builds

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
✔️	daa3695	#1	2024-09-09 15:54:02	~2 min	tests-rpc	📄log
✔️	daa3695	#1	2024-09-09 15:55:29	~4 min	linux	📦zip
✔️	daa3695	#1	2024-09-09 15:57:13	~5 min	android	📦aar
✔️	daa3695	#1	2024-09-09 16:24:35	~33 min	tests	📄log
✔️	daa3695	#2	2024-09-12 14:04:12	~5 min	ios	📦zip

[dlipicar]

we've got services/wallet/async/async.go Group for managing this repeating pattern of adding 1 to the WaitGroup and running a thingy in a goroutine. Kind of a small pattern, but it should prevent the kind of bug where you forget to add 1.
If the @status-im/status-go-guild likes it, we can extend usage of it.

[dlipicar]

oh shit just realized that class goes directly against https://www.notion.so/Code-smell-2-Pass-context-to-functions-cd49904001ca4152be006124e64f5c61
🤔

[igor-sirotin]

@dlipicar Not sure about this. WaitGroup itself is a pretty simple class and straight-forward to use. And wrapping it into such things unnecessary complicates it IMO.