Refactor entity IDs and prefixes

[zpatrick]

We could change the client and api package to always communicate with fully-qualified entity ids. This could help simplify the provider/aws package tremendously. If we wanted, users could still only be exposed to unqualified ids (e.g. the l0 cli will strip the l0-<instance>- prefix), but any call made to/from the API would communicate with fully-qualified ids.

We could also investigate removing random hashes for IDs. This has some pros and cons:

• PRO: Each entity would be human-readable both on layer0 and on the aws console
• PRO: We could remove a lot of name<->id lookups from the tag database (we can't remove them entirely; we would need to keep things like task arn->id mappings).
• CON: Users would be limited (somewhat dramatically) by the length and name requirements they can use for entities. For example, load balancer names are restricted to something like 23 characters. With the layer0 prefix, this becomes even smaller.
• CON: Tag resolving from the CLI, e.g. l0 entity get foo* would need be significantly changed. If we kept it, most likely we would need to call the List command for the specified entity first (which could be expensive).

However, we could investigate using aws tags to fill in the gaps. We may be at the point where each entity created by Layer0 has aws-supported tags.

[diemonster]

Re: CONs

• ELB names can be 32 characters. But as you pointed out re: aws tags, it seems like we could use them to fill the gap here.
• Could we consider using AWS' new tag api to do lookups? It's available in the SDK and covers things like EC2 instances, ELBs, etc: https://aws.amazon.com/blogs/aws/new-aws-resource-tagging-api/

https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/Welcome.html

[tribaljack]

Investigation for v0.11.0