Drop the DbCalcState table

[sphuber]

Fix #2197

The DbCalcState table was introduced to both keep the current job state
of JobCalculations but also to function as a sort of locking mechanism
to ensure only one process was operating on a job at a time, by enforcing
progressive state changes on the database level. In the new system, this
responsibility is taken care of by the Runner class that is running the
task corresponding to the job calculation. The calculation state is now
merely set as on the node for informational purposes to the user.

Therefore, the simpler solution is to set the job state as a simple attribute
and remove the DbCalcState. This also means that the IMPORTED calc state
is now obsolete, as that was needed to prevent imported calculations from
being picked up by the daemon, which used to determine what calculations to
run based on its calculation state.

[sphuber]

@giovannipizzi a related problem to what you were discussing with leopold today. For this PR I removed the DbCalcState model as it is no longer needed, but the second migration which was added to introduce this very model, relies on it but when it now tries to import it, it will fail. Not sure how to fix this. You have an idea of the right approach?

[sphuber]

Ah maybe the old models will be serialized and stored somewhere once I put in the migration to actually delete this model. I will check this tomorrow

[giovannipizzi]

A few interesting notes:

• Apparently the order is almost automatically fixed by Django (I don't know about alembic yet, but I think also there it can be fixed) https://docs.djangoproject.com/en/1.8/topics/migrations/#version-control ; they have a dependency tree (https://docs.djangoproject.com/en/1.8/howto/writing-migrations/#controlling-the-order-of-migrations) and IIRC also alembic has the same
• Some links on historical models: https://docs.djangoproject.com/en/1.8/topics/migrations/#historical-models
• Ho to correctly make a data migration: https://docs.djangoproject.com/en/1.8/topics/migrations/#data-migrations. Example from there:

  from django.db import models, migrations
  
  def combine_names(apps, schema_editor):
      # We can't import the Person model directly as it may be a newer
      # version than this migration expects. We use the historical version.
      Person = apps.get_model("yourappname", "Person")
      for person in Person.objects.all():
          person.name = "%s %s" % (person.first_name, person.last_name)
          person.save()
  
  class Migration(migrations.Migration):
  
      dependencies = [
          ('yourappname', '0001_initial'),
      ]
  
      operations = [
          migrations.RunPython(combine_names),
      ]

  Note the RunPython, and the fact that it will provide in the first parameter apps of its argument (a callable) the historical models, that you will get with apps.get_model. Again, I need to check for alembic.
• Before 1.0, we might want to think if we want to squash migrations (to evaluate if it's worth doing it): https://docs.djangoproject.com/en/1.8/topics/migrations/#squashing-migrations

[coveralls]

Coverage decreased (-0.2%) to 67.356% when pulling 7ac53ae on sphuber:fix_2197_drop_calc_state_table into 2f1b74a on aiidateam:provenance_redesign.