Add a `validate integrations` trigger to validate integrations without running their tests

[jsoriano]

We have the test integrations trigger that launches a full integrations build to ensure that a change doesn't break any of the packages whose source is there.

This integrations build is quite heavy as it runs all the system tests too, but in most cases, when making changes in the Package Spec, we are mostly interested on checking that validation doesn't break for any package.

Add a new validate integrations trigger that only tries to validate and build packages in the integrations repository, without running all the tests.

cc @mrodm

[mrodm]

Add a new validate integrations trigger that only tries to validate and build packages in the integrations repository, without running all the tests.

This looks perfect specially for changes performed in package-spec that just involves linting. We could have the feedback faster for these changes.

This is going to require changes in the integrations repository. The current process is based on creating a new Pull Request, and then it runs the default behaviour.

For this new automation, I think it will be needed to add support to change the behavior of the build running when a Pull Request is created. I think the Buildkite builds can read if there are GitHub labels set, so an option would be creating the Pull Request with some specific label. If that label is present, then the CI scripts should just run elastic-package check.

They would not needed neither to create a Elastic stack via elastic-package stack command.