LSIF: GraphQL enhancements

Created by: efritz

This PR improves the LSIF GraphQL API:

• removes LSIFDump and LSIFJob as these can just get a node directly by identifier
• moves LSIFDump under Repository resolver

This PR also changes code structure a bit:

• a8n and codeintel resolvers are no longer assigned to schemaResolver, but to a OptionalResolvers struct defined in the graphqlbackend package. This is necessary as the repositoryResolver (which is created directly in many places) also needs a reference to these optionally assigned resolvers (and there is no current way to pass them from the schema resolver as repository resolvers can be created independently).

Created by: codecov[bot]

Codecov Report

Merging #6589 into master will increase coverage by 0.02%. The diff coverage is 5.55%.

@@            Coverage Diff             @@
##           master    #6589      +/-   ##
==========================================
+ Coverage   39.07%   39.09%   +0.02%     
==========================================
  Files        1224     1224              
  Lines       62796    62743      -53     
  Branches     6097     6098       +1     
==========================================
- Hits        24536    24530       -6     
+ Misses      36019    35973      -46     
+ Partials     2241     2240       -1

Impacted Files	Coverage Δ
cmd/frontend/graphqlbackend/a8n.go	0% <0%> (ø)
web/src/enterprise/repo/settings/backend.tsx	0% <0%> (ø)
web/src/enterprise/site-admin/backend.ts	0% <0%> (ø)
cmd/frontend/graphqlbackend/repository.go	20.73% <0%> (-0.7%)
cmd/frontend/graphqlbackend/codeintel.go	0% <0%> (ø)
cmd/frontend/graphqlbackend/graphqlbackend.go	54.97% <20%> (+0.47%)
shared/src/util/strings.ts	13.33% <0%> (-10.2%)
web/src/search/helpers.tsx	76.72% <0%> (-0.2%)
enterprise/pkg/a8n/run/runner.go	63.79% <0%> (-0.15%)
enterprise/pkg/a8n/store.go	85.65% <0%> (-0.05%)
... and 5 more

Created by: efritz

@mrnugget I'm super open to alternate solutions here. However, I don't think this is actually making anything more global than it already was being set on the schema resolver.

Here are the places where a repository resolver is constructed: https://sourcegraph.com/search?q=repo:github.com/sourcegraph/sourcegraph%24+%26repositoryResolver%7B&patternType=literal

Most of these are not linked to a schemaResolver instance at all, and in the case of a nil codeIntel resolver, would you rather that we make the LSIF data unreachable (seems bad), or create a new sub-resolver each time (seems inefficient and has the same global consequences)?

There certainly is probably a better way, but I'm not comfortable enough with the internals here to suggest anything else (it's not obvious to me).

Created by: efritz

Couldn't we pass them to the RepositoryResolver constructors?

Are you saying we should read it from global state to pass it to the repository resolver, or was this assuming that all constructions of a repo resolver somehow had access to it? The former doesn't seem to buy us anything but errors down the line (forget to pass it once), and the latter isn't a correct assumption as far as I can tell.

Created by: efritz

Closes #6584.