runtime/secret: restore goroutine behavior to proposal

During review of CL 704615, a suggestion was made that spawning a
goroutine inside a call to secret.Do result in a panic. I agreed with
this at the time, but had missed that this had been extensively
discussed on the proposal. Revert the behavior back to what was agreed
upon.

Change-Id: Ifaa9e24bd03ecbd870ae2217137d1a9527c96842
Reviewed-on: https://go-review.googlesource.com/c/go/+/728920
LUCI-TryBot-Result: Go LUCI <[email protected]>
Reviewed-by: David Chase <[email protected]>
Reviewed-by: Roland Shoemaker <[email protected]>

Author: DanielMorsing

src/runtime/proc.go

@@ -5286,10 +5286,6 @@ func malg(stacksize int32) *g {
 // The compiler turns a go statement into a call to this.
 func newproc(fn *funcval) {
 	gp := getg()
-	if goexperiment.RuntimeSecret && gp.secret > 0 {
-		panic("goroutine spawned while running in secret mode")
-	}
-
 	pc := sys.GetCallerPC()
 	systemstack(func() {
 		newg := newproc1(fn, gp, pc, false, waitReasonZero)

src/runtime/secret/secret.go

@@ -28,7 +28,7 @@ import (
 //   - Currently only supported on linux/amd64 and linux/arm64.  On unsupported
 //     platforms, Do will invoke f directly.
 //   - Protection does not extend to any global variables written by f.
-//   - Any attempt to launch a goroutine by f will result in a panic.
+//   - Protection does not extend to any new goroutines made by f.
 //   - If f calls runtime.Goexit, erasure can be delayed by defers
 //     higher up on the call stack.
 //   - Heap allocations will only be erased if the program drops all