Add utils.Subprocesses to replace sync.WaitGroup

[topliceanu]

No description provided.

[jmank88]

This seems useful 👍 , but WDYT about keeping it super simple, like a basic extension with the same name that embeds or uses sync.WaitGroup as the underlying type?

Suggested change

	type Subprocesses struct {
	wg sync.WaitGroup
	}
	// Wait blocks until all function calls from the Go method have returned.
	func (s *Subprocesses) Wait() {
	s.wg.Wait()
	}
	// Go calls the given function in a new goroutine.
	func (s *Subprocesses) Go(f func()) {
	s.wg.Add(1)
	go func() {
	defer s.wg.Done()
	f()
	}()
	}
	type WaitGroup struct {
	sync.WaitGroup
	}
	type WaitGroup sync.WaitGroup
	// Go calls the given function in a new goroutine.
	func (wg *WaitGroup) Go(f func()) {
	wg.Add(1)
	go func() {
	defer wg.Done()
	f()
	}()
	}

Either way, you can drop the explicit Wait method.

[topliceanu]

I disagree. The main idea of Subprocesses is that users CAN'T Add() more or less than they Done().
This happens to me a lot and it's a pain to debug. With your solution, users can still get into this situation.

[jmank88]

In that case, IMHO the docs should say more about how to use this properly without assuming any knowledge of WaitGroup. For example, a naive user that calls Go() after Wait() would cause a race. Alternatively, if this was moved to package monitoring, then I think it's fine as-is - I'm just overly concerned about keeping pkg/utils API super clean/stable.

[topliceanu]

That's fair. I'll add documentation for pkg/utils#Subprocesses.

[topliceanu]

@jmank88 I had to rebase over main