`Go` lockfile generation fails with sandbox

[ejortega]

Overview

Attempting to a create a lockfile from a go.mod manifest fails with error missing $GOPATH: HOME is not set.

How To Reproduce

Steps to reproduce this behavior:

1. Parse a go.mod file

   
   ❯ phylum parse -t go go.mod
   Generating lockfile for manifest "go.mod" using Go…
   ❗ Error: Lockfile generation failed! For details, see: https://docs.phylum.io/cli/lockfile_generation

Caused by: package manager quit unexpectedly (code: Some(1)):

go: github.com/go-audio/audio@v1.0.0: verifying go.mod: github.com/go-audio/audio@v1.0.0/go.mod: initializing sumdb.Client: could not locate sumdb file: missing $GOPATH: HOME is not set

❗ Error: Could not parse dependency file "go.mod" as "go" type

Caused by: Dependency file parsing failed

2. Checking `go env` the `$GOPATH` is set.
3. After disabling the lockfile generation sandbox, the lockfile generation works as expected.
```bash
❯ phylum parse -t go --skip-sandbox go.mod
Generating lockfile for manifest "go.mod" using Go…
[
  {
    "name": "github.com/d4l3k/messagediff",
    "version": "v1.2.2-0.20190829033028-7e0a312ae40b",
    "type": "golang",
    "lockfile": "go.mod"
  },
  {
    "name": "github.com/go-audio/audio",
    "version": "v1.0.0",
    "type": "golang",
    "lockfile": "go.mod"
    ...

[cd-work]

I don't think we currently have any exception specific to Go, so $GOPATH wouldn't be read even if it's set.

[kylewillmon]

Brainstorming ways to make this work:

1. Allow access to the GOPATH variable. And parse the value to add read-write permissions for any directories listed.
2. Disallow access to the GOPATH variable and grant read-write access to the default location, $HOME/go. (But that gets complicated if that path does not exist...)
3. Create a temporary directory with read-write access and set GOPATH to point to it.
4. Exempt go from sandboxing... After all, it is designed to mitigate supply chain attacks

All of these options are a bit messy... 1 and 4 are my current favorites, but I'm going to think a bit more on this...