[ftr] support --kibana-install-dir flag

[spalger]

In certain edge cases we need to access the Kibana installation from the functional test runner via the file system, which requires that we know where it is installed. This should be a last resort option since it means the tests can not be executed against remote instances, but in a pinch this will do the trick.

[elasticmachine]

Pinging @elastic/kibana-operations

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[mw-ding]

one issue with this PR is when the --kibana-install-dir param is provided, the local functional test run will use xxx/bin/kibana xxx to spin off kibana instead of node scripts/kibana.js xxx. This will result in "cannot find /bin/kibana xxx` errors in local dev mode.

I thinking of if the functional test config service can provide a param for returning the path.data config value on the fly?

[spalger]

The thing is that we don't have access to the actual path.data config value, it could be set a number of different ways and would cause things to get really coupled together if we exposed that to the functional tests. The idea with exposing --kibana-install-dir is that we can do something like:

import { REPO_ROOT } from '@kbn/dev-utils'

const repoDir = resolve(config.get('kbnTestServer.installDir') || REPO_ROOT, 'data/repo/xxx');

When people are running the tests locally they almost always run them against source, so we'll almost always be using REPO_ROOT here, and if they're using a kibana install then they either need to disable this test or pass --kibana-install-dir to make sure that these tests can work.

[mw-ding]

LGTM. This is super helpful!

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[spalger]

7.x/7.5: 124f91c
7.4: 9f6f417