Count the take-ins and every other background work in the serving group, so serve's stop waits for them too (issue 1945)

inBackground ran the take-ins of done keys (now in #463's slots), the start's
look, the given values' replacement and the announced reads beside serve without
serve waiting for them: a take-in could outlive its controller as the loops did.
It now takes the context and is counted in its serving group as well, and a
serve that is stopping starts none.

cmd/mesh-controller/serving_group.go

@@ -29,17 +29,17 @@ func withServingGroup(ctx context.Context) (context.Context, *servingGroup) {
 
 // goServing runs work beside the caller, counted in the group ctx carries, so serve's stop waits for it. Under a group
 // whose stop began it runs nothing; under a context with no group (a part run alone, by a test or a verb) it is a plain
-// goroutine, as before.
-func goServing(ctx context.Context, work func()) {
+// goroutine, as before. It says whether it started work.
+func goServing(ctx context.Context, work func()) bool {
 	g, _ := ctx.Value(servingGroupKey{}).(*servingGroup)
 	if g == nil {
 		go work()
-		return
+		return true
 	}
 	g.mu.Lock()
 	if g.stopped {
 		g.mu.Unlock()
-		return
+		return false
 	}
 	g.wg.Add(1)
 	g.mu.Unlock()
@@ -47,6 +47,7 @@ func goServing(ctx context.Context, work func()) {
 		defer g.wg.Done()
 		work()
 	}()
+	return true
 }
 
 // stop starts nothing more and waits for what was started; the caller ends their context first. A second stop waits