symbols: add healthz endpoint (sourcegraph#1991)

gitserver: suppress false clone error log message (sourcegraph#1948)

* gitserver: suppress false clone error log message

This code used to assume `req.URL` existed and try to clone it. In reality, it only exists in certain circumstances. The end result (request failure) was the correct behavior, and that behavior remains, but attempting the clone is needless and results in a log message that is very misleading and looks like a bug on our end.

Unless you want to understand how I've confirmed this, etc. you may stop reading here. :)

Under some circumstances (such as improperly configured SSH cloning), I have observed errors from gitserver like:

```
t=2019-01-16T07:25:26+0000 lvl=dbug msg="error cloning repo" repo=github.com/slimsag/private-repo err="error cloning repo: repo github.com/slimsag/private-repo ([email protected]:slimsag/private-repo.git) not cloneable: exit status 128 (output follows)\n\nHost key verification failed.\r\nfatal: Could not read from remote repository.\n\nPlease make sure you have the correct access rights\nand the repository exists.\n"
t=2019-01-16T07:25:26+0000 lvl=dbug msg="error cloning repo" repo=github.com/slimsag/private-repo err="error cloning repo: repo github.com/slimsag/private-repo () not cloneable: exit status 128 (output follows)\n\nfatal: no path specified; see 'git help pull' for valid url syntax\n"
```

Fundamentally, the problem here is that there is an inaccessible repository (e.g. the user has not configured authentication for that repo correctly).

However, the second log message is very strange in nature and looks like we might have a serious bug: why would we try to clone something via git without specifying the URL?

I've spent a long time debugging this and trying to track down the cause, and a user also thought this might indicate a more serious issue somewhere.

Per the documentation on [`gitserver.Repo.URL`](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@e6d353a1a6c7282da4c68573b6fafc7cdccc32fc/-/blob/pkg/gitserver/client.go#L224-227),
the URL field is optional and not always present:

```Go
// URL is the repository's Git remote URL. If the gitserver already has cloned the repository,
// this field is optional (it will use the last-used Git remote URL). If the repository is not
// cloned on the gitserver, the request will fail.
URL string
```

Looking at [`gitserver.Repo`](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@e6d353a1a6c7282da4c68573b6fafc7cdccc32fc/-/blob/pkg/gitserver/client.go#L221:6&tab=references)
references shows this is indeed often the case.

The behavior we have today when executing git commands can be simply summarized as: "If the repository doesn't exist, we try to clone it. If we can't clone it, the git exec request fails."

But how does that actually happen in practice? During git exec requests, [we clone the repo if the directory doesn't exist](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@e6d353a/-/blob/cmd/gitserver/server/server.go#L565-568):

```Go
	if !repoCloned(dir) {
		cloneProgress, err := s.cloneRepo(ctx, req.Repo, req.URL, nil)
		if err != nil {
			log15.Debug("error cloning repo", "repo", req.Repo, "err", err)
```

And therein lies the problem: we don't have a `req.URL` and yet we're trying to clone using it.

* make errcheck linter happy

finish removing external services

Revert "require admin permissions for repo count"

This reverts commit dd05c28.

Fix regressions in discussions (sourcegraph#1850)

* Fix regressions in discussions

all: Fix import paths of migration tool (sourcegraph#1818)

cmd/frontend/db: fix issue where JSONC was incorrectly treated as JSON (

fixes sourcegraph#1540) (sourcegraph#1714)

Prior to this change this code tried to treat JSONC as `json.RawMessage` but
that is of course not legal because JSONC can contain comments, missing trailing
commas, etc.

site config: remove "scratch area" warning + remove "source: database" (

sourcegraph#1693)

* site config: configuration is now always editable

Fixes sourcegraph#1436

* remove SiteConfiguration.source information (it is always in the DB now)

Fixes sourcegraph#1434

move into doc

cmd/management-console: switch to yarn