refactor: validate and parse the endpoint and proxy at program load

[peterguy]

Summary

Parse the endpoint URL at program load instead of passing around an unparsed string and needing to check/parse it in multiple places.

Changes

config struct (cmd/src/main.go)

• Un-export fields (all consumers are in package main)
• Add endpointURL, remove endpoint and proxy
• Parse once in readConfig; consumers use the parsed URLs

api.ClientOpts (internal/api/api.go)

• Endpoint string → EndpointURL *url.URL
• Use JoinPath for URL construction instead of string concatenation with TrimRight

login command (cmd/src/login.go)

• loginCmd now uses the config's endpointURL
• Endpoint conflict detection moved from loginCmd into the handler, where the CLI arg is parsed and compared before entering the command

code_intel_upload (cmd/src/code_intel_upload.go)

• makeCodeIntelUploadURL uses a stack copy (u := *cfg.endpointURL) instead of re-parsing the URL
• Error return removed since there's nothing that can fail

Tests

• Updated all test call sites to pass *url.URL
• Added "net/url" imports where needed

Testing

All affected packages pass:

ok  github.com/sourcegraph/src-cli/cmd/src
ok  github.com/sourcegraph/src-cli/internal/api
ok  github.com/sourcegraph/src-cli/internal/batches/repozip
ok  github.com/sourcegraph/src-cli/internal/batches/executor

[peterguy]

coy by dereference makes a shallow copy - affects User mostly/only - should we include a comment to that effect here?

[peterguy]

The existence of this check calls into question the command-line parameter - SRC_ENDPOINT (or the value from the config file) is the source[1] of truth, forcing the user to put the same value on the command line.
Adding to the confusion is that if there is nothing in the config file or in SRC_ENDPOINT, cfg.endpointURL defaults to https://sourcegraph.com, which is probably wrong pretty much all of the time, and still invalidates anything different on the command line.
I kept the error condition and message (although I did change the semantics by changing from an exit error to a usage error) because I didn't want to rip that rug out from under anyone at this point.
Thoughts?

[1] no pun intended, but I do like it

[peterguy]

The config file has been deprecated for a long time, but if it ever is finally removed, the ability to set additional headers will go also. Do we need to keep the ability to set additional headers around? If so, we should probably introduce yet another environment variable for those and delay the config file removal. If not, let's complete the config file deprecation!