Adds a `runNow` api to Task Manager, allowing us to force the refresh of a recurring task.
This PR includes a couple of sustainability changes as well as the feature itself.
1. **Declarative query composition.** At the moment the queries in the TaskStore are huge JSON objects that are hard to maintain and understand. This PR introduces a pattern where the different parts of the query are composed out of type-checked functions, making it easier to maintain and to construct dynamically as needs change. _This was included in this PR as the **markAvailableTasksAsClaimed** query needs different query clauses depending on whether there are specific Tasks we wish to claim first.
2. **Refactoring of the Task Poller** As the `runNow` api is introduced we find Task Manager's lifecycle in a weird state where it has both a _pull_ model, where timeouts & callbacks interact without having to responsd to any external requests, and a _push_ model where requests are made to the new `runNow` api. Balancing these two proved error prone, hard to maintain and had the potential of _lossy_ behaviour where requests are dropped accidentally. To address this TaskPoller has been refactored using Rxjs observables, remodelling the existing _pull_ mechanism as a _push_ mechanism so Task Manager can _respond_ to both _polling_ calls and _runNow_ in a similar fashion.
And ofcourse the main feature of this PR:
3. **runNow api** An api on TaskManager that takes a _task ID_ and attempts to run the task. The call returns a promise which resolves with a result which notifies the caller when the task has either completed successfully, or result in an error.
Ensure no deprecated Node.js core API's are used in Kibana. This is
achieved by throwing an error in either development mode or in CI if one
of the deprecated API's is called, and as such, new PR's should no
longer be able to be merged if they use deprecated API's.
Some of these API's (like the `Buffer` constructor`) is a security risk.
Instruments Kibana with Elastic APM by adding the Node.js agent to the
source code. The agent is not turned on by default but can be enabled by
setting the environment variable `ELASTIC_APM_ACTIVE=true` or by
creating an apm config file called `config/apm.dev.js` and setting
`active: true` inside of it.
This implementation is not meant to be used by end-users of Kibana as it
lacks integration with the regular Kibana config file. For now, this is
meant as a useful internal tool for Elastic employees when developing
Kibana.
By default, it's pre-configured with a `serverUrl` pointing to an APM
Server hosted on Elastic Cloud. The data is stored in an ES cluster
accessible only by Elastic employees. These defaults can easily be
overwritten using environment variables or via the custom config file.
This adds an absolute session timeout (lifespan) to user sessions.
It also improves the existing session timeout toast and the overall
user experience in several ways.
* run mocha tests from x-pack with root mocha script
* Only run Karma tests in xpack intake job
* disable failing suites
* fix typo
* skip correct suite (there are multiple root suites)
* support disabling junit reporting with $DISABLE_JUNIT_REPORTER
* don't generate junit in ispec_plugin tests
