Update schema to new plan

[MarkKoz]

Resolves #48

• Instead of a boolean is_manual field, a parameter now has a type field which can be either automatic, semi-automatic, or manual.
• The parameter now has a field to store the sensor ID. This field is unique per-device, meaning for a specific device, there can only be one parameter for that sensor.
• Parameters and tests are one-to-one now. This means each parameter can only be associated with one test, and each test can only be associated with one parameter. Furthermore, this relationship cannot be updated (i.e. cannot change a test's parameter after the test has already been created).
  • Parameters have a device foreign key now. A parameter's device cannot be changed once the parameter is created.
• Removed the priority for tests. Given the concurrent nature of scheduling, it would be too difficult to implement a priority system for simultaneous requests.

There are quite a few custom migrations which were maybe a waste of time in hindsight. Both their application and reversal has been tested by me. The only migration that cannot be revsered is the one which deletes the priority field; the migration has no idea what the data in that column was and thus cannot restore it.

Either this PR or #60, depending on which is merged first, will need to be updated to account for the schema changes.

[MarkKoz]

Actually there is an issue with line 41 of 0006_parameter_test_1to1_2:

django.db.utils.IntegrityError: duplicate key value violates unique constraint "api_test_pkey"
DETAIL:  Key (id)=(2) already exists.

It seems if I keep trying to run the migration, it will eventually use an ID that isn't a duplicate. But the idea was for it to automatically figure out the next ID to increment to. For some reason that isn't working.

[MarkKoz]

I don't really want to spend time on fixing the migration bug right now. In practice, it would only happen if the DB is already populated with some tests when the migration is applied. Since we haven't deployed to production yet, any data in the DB is just local data for development purposes. The workaround is to either clear the database or just keep trying to apply the migration until it finally uses the right ID.