EC2 migration to the new architecture

[Aboisier]

This PR is a work in progress for refactoring the EC2 service, as part of the #183 issue.

I was doing a lot of copy-pasting in between the Lambdas service and this one, and between the facade methods, so I generalized some classes and methods.

EC2 has a pretty complex structure, but it seems like our new architecture holds up.

• EC2
  • regions
    • region_id
      • images (contains a dictionary of images)
      • snapshots (contains a dictionary of snapshots )
      • volumes (contains a dictionary of volumes )
      • vpcs
        • vpc_id
          • instances (contains a dictionary of instances)
          • network_interface (contains a dictionary of nics)
          • security groups (contains a dictionary of sgs)

Stuff I generalized:

Regions

Fetches a list of all the regions and builds a regions dictionary with <region_id, empty_dictionary> key pairs. It also sets the regions_count

ScopedResource

Abstract class which fetches resources in a given scope. The child class needs to define a get_resources_in_scope(scope) method. The scope can be anything; a region, some VPC id, etc. It also needs to define a parse_resource(resource) method which returns a (resource_id, resource) tuple. The ScopedResource class loops and sets the resources in its own dictionary.

[misg]

Just left a couple of comments that are mainly details and not very important ones, I'm up for a merge! 🎆 Great job overall, special mention to your unit tests for AWS resources, very neat! 🥇

[misg]

I think we got an opportunity with this migration to be PEP 8 compliant and start defining dictionaries like the following:

        instance = {
                'id' = raw_instance['InstanceId'],
                'reservation_id' = raw_instance['ReservationId'],
                'monitoring_enabled' = raw_instance['Monitoring']['State'] == 'enabled',
                'user_data' = self.facade.ec2.get_instance_user_data(self.scope['region'], id)
        }

[Aboisier]

I had a discussion about that with @Remi05 last Thursday and we came to the conclusion it's probably a better idea to continue with the current implementation. There were a couple of reasons why, but here are the most important IMHO:

1. Easier debugging: let's say raw_instance['InstanceId'] fails because the dict does not have this key. Using the PEP 8 convention, we would not know exactly what caused the crash.
2. Add stuff iteratively: Sometimes, you want to add stuff iteratively. That's not possible with the PEP 8 convention unless you want to use a hybrid of the two notations, but then we might as well keep up with the current solution

[misg]

Same comment as above.