Add AWS EC2 resource autodetection

[fbogsany]

Follow on from open-telemetry/opentelemetry-ruby#230 and open-telemetry/opentelemetry-ruby#263.

[rydzykje]

I'm Ruby noob but will be happy to learn something and help with that.

[fbogsany]

Thanks @rydzykje - I've assigned this to you.

[plantfansam]

I did a little research into this ticket, and I wanted to get some clarification before trying anything silly. Please forgive any naivete, as I'm new to Open Telemetry!

So this ticket differs from sibling GCP implementation in open-telemetry/opentelemetry-ruby#263 because Google Cloud provides a lovely Ruby gem that gives a lot of the data that the specification wants. As far as I can tell, there's no AWS equivalent to that GCP gem (would love to be wrong about this, though!). As a workaround, the JS EC2 detector hits the instance identity document endpoint to fill out the details of the resource.

This investigation makes me wonder a couple things:

• The EC2 instance identity document is accessed via a link-local address. I'm concerned that an HTTP request to that link-local address might run very slowly in the event that this detector is run outside of an EC2 context. Is that a concern here? If so, is there an established method for dealing with that in this particular gem? The JS implementation seems to use async but that doesn't map cleanly to native Ruby functionality AFAIK.
• AWS offers a lot a lot of different places to run code. EC2 is a big one, but Lambda, Fargate, and so on; these are all places that this gem might want to auto-detect. Should that be considered as part of this issue, or is that a separate thing?

[fbogsany]

This issue is specifically about EC2, but we'd be happy to see contributions around any of those environments. If it's a ton of work to support all the environments, then delivering them one at a time is probably better, but otherwise a single PR covering all of them would be fine.

an HTTP request to that link-local address might run very slowly in the event that this detector is run outside of an EC2 context. Is that a concern here? If so, is there an established method for dealing with that in this particular gem?

We're planning to refactor the resource detectors gem to extract the GCP support to a separate gem. Other detectors should also be separate gems. That will allow users to only require the detectors for the environments they use and not suffer the performance penalty from other detectors.

[plantfansam]

Ah, wonderful! Thanks so much for the clarification. I'll try to start with EC2 and see where it leads.