Question: why go_test fails for ENOMEM

### What version of rules_go are you using?

V0.29.0

### What version of gazelle are you using?

V0.24.0

### What version of Bazel are you using?

V5.0.0

### Does this issue reproduce with the latest releases of all the above?

I'm not sure.

### What operating system and processor architecture are you using?

Ubuntu 20.04.3 LTS
x86_64

### Any other potentially useful information about your toolchain?

### What did you do?

I tried to debug an ENOMEM error which only appears when race detector enabled.

### What did you expect to see?

Either the testcases succeeds, or it fails with stacktrace, so that I could debug how actually does memory allocation.

### What did you see instead?

`==12==ERROR: ThreadSanitizer failed to allocate 0x2b59000 (45453312) bytes at address 175df95610000 (errno: 12) `

I understand golang race detector could use 5x, or even 10x, memory than normal.

But according to the error message above, it's only consuming 45MB, which doesn't seem to be a large chunk of memory.

I tried to debug with gdb and set breakpoint. But two things I don't understand:

```
h@h-desktop$ nm bazel-out/k8-dbg-ST-61abbe76aa1f/go_default_test_/go_default_test
nm: bazel-out/k8-dbg-ST-61abbe76aa1f/go_default_test_/go_default_test: no symbols
```
First question, I compiled go-test with `bazel build -c dbg`, it seems symbol table has been stripped.
Also tried to add flag
```
gc_goopts = [
"-N", # no optimization
"-l", # no inline
],
```
These two flags works when I'm directly compiling with `go build`, but still no symbol table found.

Second question, I tried to set breakpoint at `sbrk`, where memory allocation goes to.
```
(gdb) bt
#0 __GI___sbrk (increment=135168) at sbrk.c:32
#1 0x00007ffff7a2abbd in __GI___default_morecore (increment=) at morecore.c:47
#2 0x00007ffff7a255a5 in sysmalloc (nb=nb@entry=656, av=av@entry=0x7ffff7b7ab80 ) at malloc.c:2470
#3 0x00007ffff7a267c3 in _int_malloc (av=av@entry=0x7ffff7b7ab80 , bytes=bytes@entry=640) at malloc.c:4141
#4 0x00007ffff7a269ab in tcache_init () at malloc.c:2982
#5 0x00007ffff7a27c3e in tcache_init () at malloc.c:3044
#6 __GI___libc_malloc (bytes=64) at malloc.c:3044
#7 malloc_hook_ini (sz=64, caller=) at hooks.c:32
#8 0x0000555556501eb9 in operator new(unsigned long) ()
#9 0x000055555649ea9f in google::protobuf::internal::OnShutdownRun(void (*)(void const*), void const*) ()
#10 0x000055555648f9aa in google::protobuf::internal::InitProtobufDefaultsSlow() ()
#11 0x0000555556447120 in ?? ()
#12 0x00005555565b9b6d in __libc_csu_init ()
#13 0x00007ffff79b2040 in __libc_start_main (main=0x555555a73480 , argc=1, argv=0x7fffffffdf08, init=0x5555565b9b20 <__libc_csu_init>,
fini=, rtld_fini=, stack_end=0x7fffffffdef8) at ../csu/libc-start.c:264
#14 0x0000555555a0a7ae in _start ()
```

The stacktrace seems weird to me, since I don't think my code involves google protobuf. The uncertainty comes from `??`, which is lost due to stripped symbols.

Start with the reported `bazel build -c dbg` command, the race-enabled `go_default_test` binary, and the `gc_goopts` settings. Reproduce the ENOMEM failure and inspect how the generated test binary handles symbols; done means explaining the allocation failure and why the expected debugging symbols are absent.

Written by the indexing model from the issue text.