[Telemetry] collect xpack.cloud details

[Bamieh]

Removal of found plugin in cloud will break the ability in telemetry to determine if the metrics are coming from Cloud or not.

This Change adds the following to the telemetry metric under plugins:

{
   plugins: {
      cloud: {
        isCloudEnabled: true | false,
      }
   }
}

if cloud is not enabled, the telemetry will report isCloudEnabled: false. I favored this over not reporting at all when cloud is not enabled with the motivation to keep the telemetry object consistent in all cases.

[epixa]

I think the cloud id includes the uuid in plaintext. If so, that's probably the value we'd want to send rather than the whole cloud id.

The term id in this case is a little ambiguous, but it's really more than just a unique identifier.

Someone from the cloud team might be able to clarify here, and you can see cloud ids in action via the beats modules getting started instructions from the Kibana home page of a cluster deployed in Elastic Cloud.

[elasticmachine]

Pinging @elastic/kibana-platform

[Bamieh]

@epixa i added the elasticsearch cluster uuid as esUUID. I kept the whole cloud ID because it is small and we can derive other information from it. Removed after Uri's message.

[elasticmachine]

💚 Build Succeeded

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

[epixa]

LGTM

[tsullivan]

any reason to not check that the type is a string?

[Bamieh]

Both should work for our case.

Checking for 'falesy' ids might protect us from unpredicted scenarios (empty string ids etc). More importantly; Checks for isCloudEnabled in other places in our code use !!id so this also ensures consistency (I'd favor consistency personally).

[tsullivan]

++ for consistency