config file override fixes + improvements

Created by: slimsag

This PR:

1. Fixes a deadlock that was introduced when specifying EXTSVC_CONFIG_FILE (caught by our deadlock detector in dev environments https://github.com/sourcegraph/sourcegraph/issues/4123).
2. Removes an incorrect "Dev" label applied to EXTSVC_CONFIG_FILE-created services
3. Fixes the previously extremely poor behavior of EXTSVC_CONFIG_FILE where it would do nothing if you have external services already (see https://github.com/sourcegraph/sourcegraph/commit/d3a714eb8d35ffb6df949eeeed34b0a8e7246e75 for why this sucked particularly bad in dev environments, too).
4. Improves error messages returned by config override files.
5. Prevents updates to extsvc/site/critical configs when they are loaded from a file (the latter requires setting an env var on the management console). This does not apply in dev mode.

My intent is to cherry-pick for release in 3.4.1.

Supercedes #4126 (in particular the first commit b46bc7d does) Fixes #4123 Fixes #4108

Test plan: manual (very difficult to test automatically currently)

Created by: slimsag

A quite notable change here is that prior to this I suspect almost everyone's dev environments external services were out of date with what was in dev-private despite often having the latest site/critical config from there.

Created by: codecov[bot]

Codecov Report

Merging #4154 into master will decrease coverage by 0.01%. The diff coverage is 0%.

Impacted Files	Coverage Δ
cmd/frontend/internal/cli/config.go	20.63% <0%> (-0.17%)
cmd/frontend/internal/cli/serve_cmd.go	2.12% <0%> (-0.02%)
cmd/management-console/shared/main.go	10.32% <0%> (-0.28%)
cmd/frontend/graphqlbackend/site.go	3.33% <0%> (-0.08%)
cmd/frontend/graphqlbackend/external_services.go	0% <0%> (ø)
cmd/frontend/db/external_services.go	10.28% <0%> (ø)

Created by: slimsag

cherry-picked onto 3.4 branch.

Created by: mrnugget

Thanks for fixing this!

caught by our deadlock detector in dev environments

I'll take one business card with that title on it, please!

Created by: keegancsmith

We run migrations on the external services in repo-updater at startup. How will this work in the world where the external service configurations are immutable?

At a technical level repo-updater will update the DB. But if frontend restarts it will then overwrite the migrations. This can lead us into a weird state. However, if the configuration passes our schema validation then the weird state is acceptable / the migrations will (currently) not run again.

Created by: keegancsmith

cc @sourcegraph/core-services @slimsag see my previous comment.