[Discover] Add context awareness telemetry tests for Observability profiles

[davismcphee]

Summary

As suggested in #199255 (comment), I've copied and modified the existing Discover context awareness telemetry tests to work for Observability profiles. This helps test that solution root profiles are picked up as expected, as well as giving us some serverless coverage.

@elastic/appex-qa It didn't seem like there were any config specific services for serverless tests yet, so I added the EBT to services to the main serverless config. If there's a better way to do this, please let me know and I can update it.

Checklist

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
• This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The release_note:breaking label should be applied in these situations.
• Flaky Test Runner was used on any tests changed
• The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines

[kibanamachine]

Flaky Test Runner Stats

🎉 All tests passed! - kibana-flaky-test-suite-runner#7468

[✅] x-pack/test_serverless/functional/test_suites/observability/config.ts: 25/25 tests passed.

see run history

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[elasticmachine]

Pinging @elastic/obs-ux-logs-team (Team:obs-ux-logs)

[jughosta]

LGTM, thanks!

[tonyghiani]

LGTM

[pheyos]

Can you help me understand what this plugin is doing?
Asking because if this is something-test-only where the behavior is different to what we have in a real serverless environment, then tests based on this would fail when running against MKI. In this case, this config entry should move to a separate config (see e.g. here how it's done for the example plugins), which doesn't run against MKI.
If it simulates MKI behavior locally, then it can stay. Would probably be good to add a comment explaining it in that case.

[davismcphee]

@elastic/kibana-core could confirm for sure since they maintain the service, but I'm pretty sure this does alter the behaviour because it adds a custom analytics shipper to capture EBT events in tests. I added a separate config for the telemetry tests here: 67a5954.

I also wasn't really sure how to handle the custom services to make sure they aren't available where they won't work, so I tried to do something similar to what was done for API integration tests: 38b9306. Let me know if you think there's a better way to do this and I can update.

[jbudz]

.buildkite/ftr_oblt_serverless_configs.yml

[elasticmachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 67a5954

Failed CI Steps

• Jest Tests #14

Test Failures

• [job] [logs] Jest Tests #14 / FilterPopover renders empty label correctly

Metrics [docs]

✅ unchanged

History

• 💚 Build #254095 succeeded c81afdb
• 💔 Build #253828 failed 69ebd46
• 💛 Build #253773 was flaky 5bc5373
• 💔 Build #253422 failed 50f5f66

cc @davismcphee

[davismcphee]

@tonyghiani I noticed this wasn't updated when we added the observability folder but I figure it makes sense to share ownership here.

[davismcphee]

@elastic/kibana-core could confirm for sure since they maintain the service, but I'm pretty sure this does alter the behaviour because it adds a custom analytics shipper to capture EBT events in tests. I added a separate config for the telemetry tests here: 67a5954.

I also wasn't really sure how to handle the custom services to make sure they aren't available where they won't work, so I tried to do something similar to what was done for API integration tests: 38b9306. Let me know if you think there's a better way to do this and I can update.