[libbeat]image.id and account.id for add_cloud_metadata EC2

[odacremolbap]

Continuing @jbagel2 effort on #10914

Adding to libbeat add_cloud_metadata processor's EC2 implementation:

• image.id
• account.id

Note: image.id is not part of ECS, but sounds like a feasible name whether it is included or not in a future ECS reference.

Tests have been unified into a single test cased test, and account.id and image.id has been added to checks.

[odacremolbap]

cc @ruflin @webmat @kaiyan-sheng

[exekias]

I see a few renames, this makes this a breaking change, isn't it?

[odacremolbap]

afaik this is not a breaking change for now

• 2 fields have been added at EC2 metadata
• renames have only been introduced at docs to sync with code

[exekias]

sorry you are right! change LGTM, it seems it needs a mage fmt

[ruflin]

Change LGTM but it needs a changelog about the 2 added fields.

[odacremolbap]

thanks for the reviews

I was silently expecting some comments regarding this file:
https://github.com/elastic/beats/blob/master/libbeat/processors/add_cloud_metadata/_meta/fields.yml

@ruflin I guess that yaml sounds like global to all cloud metadata, and shouldn't be touched until we bring those 2 fields to all other cloud providers. If I'm wrong, pls, correct me

[exekias]

You can definitely add them there, I see cloud.project.id is in (GCP only?). If/Once these new fields make it to ECS you can import ECS and remove them from this fields.yml

[exekias]

@odacremolbap you didn't add the fields, something is wrong here?

[odacremolbap]

@exekias I'll open a new issue to gather that info (image, account) from other providers, then once they are available for all (or most) add it

[exekias]

why not adding them now? that would mean master is missing these fields, while they may be reported in some cases. It sounds like having fields.yml in is a safer play, you can always change them when adding new providers