GitLab

By default, the IP log contains the history of all IPs, both floating
and private. However, showing the IP history for private IPs has two
serious drawbacks:

1) Address class between floating-private IPs.

There are cases when some floating IPs and public IPs have the same
address name. In this case, it is not easy to the history only for the
private or floating IP, since the IP type is not registered in the log.
What's registered however is a network id from which we can extract this
information. However, this means that in order to get details for an IP,
we need to have its latest network ID, which may not be available for
old entries in the IP log and further complicates things.

2) Private IPs are one-use only.

A private IP cannot be detached from a VM and be given in another VM, at
least not in the same way as floating IPs are detached. A private IP
lives as long as a VM is connected to a private network, and then gets
destroyed. This info is not very useful.

Unify filters for a model field. Each table view has a list of filters,
one for each associated model. Every filter by default receives a list
of keywords and filters the respective model using a predefined set of
fields.

The user can override the default fields and define its own using the
operator "=".

For example, in a User filter, the query "John" will search by default
in the following fields: first_name, last_name, uuid. On the other hand,
the query "first_name=John" will search only in the field specified at
the left of the "=" operator.

Fix apyrgio/synnefo#179

Fix bugs in filters due to earlier (0.5.3-3) django-filter version.

The main issue was that django-filter could not handle inherited fields.

Fix apyrgio/synnefo#202

Make the filter handle the server prefix, if given.

Fix apyrgio/synnefo#138

Enable filtering by project/application status or by "is_base"
property.

Fix apyrgio/synnefo#75 and also fix apyrgio/synnefo#95.

The current code structure was leading to circular imports of the files
that are responsible for each entity. To solve this, we must break each
of those files to smaller pieces.

The pieces that each of the files are broken into are:

* views: The functions that implement the views for each entity.
* actions: The functions that have to do with the actions on each
  entity.
* filters: The functions that have to do with filtering.
* utils: Auxiliary functions.

With the new structure, the users' views can import the vms' actions and
the vms' views can import the users' actions without worrying about
circular imports.