job id: update server to use the same unique job id schema as avocado itself

This means that:
 - we have a copy of the same job id generation code as avocado
 - it is used as the only job identification
 - no automatic incremental integer as a primary key for a job

Signed-off-by: Cleber Rosa <crosa@redhat.com>
avocadoserver/serializers.py: adapt to new state of Job fields

Including the new intended use of the `id` field, which is no longer
read only, quite on the contrary, should be given by the user.

Signed-off-by: Cleber Rosa <crosa@redhat.com>
avocadoserver/views.py: remove all custom logic in the Job viewset

Previously, we had custom code to locate a Job either by its internal
auto incremental id (the data model primary key) and also the so
called unique identification (uniqueident).

Now that only a single field is used, remove all the custom logic,
including the `retrieve()` method that was causing a lot of funky
behavior.

Signed-off-by: Cleber Rosa <crosa@redhat.com>
avocadoserver/models.py: fix unique constraint on Test model

It's *not* OK for a given test (identified by a tag) to have multiple
(even if unique) results. So, now the configuration limits a given
test to one and only one status per job.

Signed-off-by: Cleber Rosa <crosa@redhat.com>
unittests: make directory structure more similar to current avocado

Try to maintain the directory structure closer to what is in the main
avocado project.

Signed-off-by: Cleber Rosa <crosa@redhat.com>
functional test: introduce an initial version

This first test named like that (api) because it tests the exposed API.

One current limitation is that the provisioning of the API server is
rather manual, so the test can not be run fully automatically. In
the near future we intent to provision it automatically during test
setup.

Signed-off-by: Cleber Rosa <crosa@redhat.com>
Merge pull request #7 from clebergnu/jobid_sha1

Job ID as a SHA1