Next we'll be trimming down ServerFacade to the final few dependencies,
and using our plugin dependencies for the rest.

For now, let's try to simplify our typings by exporting our plugin's
dependencies from the plugin itself, since we know it already knows
about them.

I'm throwing the alerting registration in the plugin for now, too.

Now that we've audited our use of request objects, we can switch to the
more friendly LegacyRequest that all our utilities are expecting.
LegacyRequest doesn't have plugins, either, so our only remaining errant
usage is retrieving clients from it, which we call out explicitly.

This just threw an error on startup, so I'm fixing all of them to be
safe.

These come through as new KibanaRequests and not as the LegacyRequest
that I had incorrectly typed them as.

I'm only caring about the `body` property right now, since that's all we
really deal with, and in testing it was all that was populated in our
actual requests, too.

We're using the legacy version for now, but ServerFacade will be gone by
the end of the migration.

This changes the signature of getIndex, which is used in quite a few
places. We'll see how bad that looks in the next commit.

We're already ignoring another portion of the platform shim due to it
being incompatibly typed, so we might as well remove this.

This contains our legacy stuff for now. Eventually, it will only be our
NP services. This breaks a few tests due to the way createMockServer
works, but I'll clean that up momentarily.

The createMockServer helper does a few things differently:

* returns mocked LegacyServices that can be passed to our route
factories
* does not return a server object as we don't need it, except for:
* returns an inject function that we can use to execute a request

We're casting our services because we're only mocking a subset of what
LegacySetupServices entails.

Mainly, this allows me to continue moving
things off of ServerFacade without significant refactoring of tests.

Unfortunately, LegacyRequest does not allow a request's `query` values
to be anything other than a string or string[]. However, in practice
they can (and are) objects, booleans, etc.

Our request types (e.g. QueryRequest) are correct, but because service
functions are LegacyRequest's implementation of `query`, we need to cast
them lest a type error occur.

For now, the easiest solution is to do this in the request handler:
intersecting with our RequestFacade (LegacyRequest) allows us to both a)
pluck our query params off the request and b) pass the request to NP
services.

We're just retrieving a boolean from it right now, which is also guarded
against the plugin being unavailable. If this usage becomes more
widespread, we'll make this available at a higher level, probably in
redux.

* Simplifies our generic type to accept two arguments: params and the
return value
  * Options is fixed and we were never specifying anything meaningful
  there
* Updates all DE cluster calls to use callWithRequestFactory

* createMockServer now returns the callCluster mock, so that you can easily
mock a client response without needing to know the details of how we
define that function

This was added during a refactor, but we were never actually using this
code. We always retrieve the client from the request via
getSavedObjectsClient.

I think that the NP client has a slightly different interface, so we're
going to create a helper to retrieve it from the request, same as we do
with the elastic client.

In the future, both of these will be available on the request context,
and we can remove the helpers entirely.

In trying to migrate over the savedObjectsClient, I realized that it is
not available during setup in the same way that the ES client is.

Since our routes need pieces from both setup and start phases, I've
added a Services class to accumulate/transform these services and expose
scoped clients when given a legacy request.

In New Platform, these clients will be available upon the request
context and we should be able to remove getScopedServicesFactory for our
routes. A subset of Services' functionality may still be useful, we'll
see.

I decided that config shouldn't live in here, as this is only
client-related stuff. Probably going to rename this ClientsService.

Things are still very much broken.

This gets us client-related services (ES, SavedObjects, Alerts), but it
is independent of any configuration, which is gonna be another service.

This is a weird helper, I'm not really sure where it should go.

Return clients, as this is closer to what we'll get in the request
context.

* Declare legacy types at top-level file
* Don't re-export from the plugin solely for convenience, that's a
slippery slope straight to circular dependencies
* Remove RequestFacade as it was a facade for LegacyRequest
* Rename ServerFacade/LegacySetupServices to just LegacyServices

* Separates config, server, and client mocks, as they're now independent
in our system, route-wise.
* gets one test working, the rest will follow.

* Adds mock for our new clients service
* Greatly simplifies both server and mock configs
* Renames factory method of client service

These work fine in production, but it's graphQL so we don't really need
the additional validation of these endpoints, and we weren't leveraging
these types anywhere in Typescript land.

Additionally, these restrictive validations prevent the initial
introspection calls done by graphiQL to get schema information, and
without schemae graphiql wasn't very helpful. This is a dev-only
problem, but that's the audience of graphiql.

This was only registered in dev mode; I thought that it was needed by
graphiql. However, after digging further I realized that graphiQL also
only makes POST calls to our real graphQL endpoint, so this route is
unnecessary.

After a little more introspection I realized our FrameworkAdapter
doesn't need the kibana version. It was only used in order to make a dev
request via (graphiql), but even that can be performed with a simpler
xsrf header.

This meant that we really only wanted to know whether we're in
production or not, so instead we pass that simple boolean to the
constructor.

We no longer need this property.

Uses the new routes interfaces, and our corresponding new mocks.

Our savedObjectsClient is always going to be there.

YAGNI

Turns out we were only destructuring this client for the null check.

We already null-coalesce properly in the clients service, but this
property access was missed.

I think that this was the result of us importing the wrong AlertsClient
type, or perhaps the types were out of sync. Regardless, they work now.

This will allow users with spaces disabled to enable spaces without
losing data. The tradeoff is that they may be surprised when signals
don't exist within their configured xpack.siem.signalsIndex.

 Conflicts:
	x-pack/legacy/plugins/siem/server/kibana.index.ts
	x-pack/legacy/plugins/siem/server/lib/detection_engine/routes/index/create_index_route.ts
	x-pack/legacy/plugins/siem/server/lib/detection_engine/routes/index/delete_index_route.ts
	x-pack/legacy/plugins/siem/server/lib/detection_engine/routes/rules/add_prepackaged_rules_route.test.ts
	x-pack/legacy/plugins/siem/server/lib/detection_engine/routes/rules/add_prepackaged_rules_route.ts
	x-pack/legacy/plugins/siem/server/lib/detection_engine/routes/rules/create_rules_route.ts
	x-pack/legacy/plugins/siem/server/lib/detection_engine/routes/rules/delete_rules_bulk_route.ts
	x-pack/legacy/plugins/siem/server/lib/detection_engine/routes/rules/find_rules_route.ts
	x-pack/legacy/plugins/siem/server/lib/detection_engine/routes/rules/update_rules_bulk_route.ts
	x-pack/legacy/plugins/siem/server/lib/detection_engine/routes/rules/update_rules_route.ts
	x-pack/legacy/plugins/siem/server/lib/detection_engine/rules/types.ts
	x-pack/legacy/plugins/siem/server/lib/detection_engine/types.ts

 Conflicts:
	x-pack/legacy/plugins/siem/server/lib/detection_engine/routes/utils.test.ts
	x-pack/legacy/plugins/siem/server/lib/detection_engine/routes/utils.ts

* Updates types to reflect that spaces may be unavailable
* Adds a test for getSpaceId's behavior when spaces are disabled

* Refactors mock expectations so that they're actually evaluated; they
can't go within a mockImplementation call as it's evaluated in the wrong
scope.
* Fixes duplicated test to use the proper assertions