Version checks between local and remote projects

[ckoerber]

In the scenario where a user communicates with a central database running different table definitions (different migration histories), it might happen that intermediate objects are inserted before the user code crashes.

This can be prevented by running checks on the import of EspressoDB (the init() function).
Things to cross check are:

(1) The version of EspressoDB
(2) The version of the EspressoDB project if applicable
(3) The migration history

The execution of checks should be optional to allow rapid development--nevertheless, this information should be on a prominent doc page.

• The migration history check can be realized by the default mechanics of makemigrations.
• EspressoDB and EspressoDB project versions must be inserted in the database when migrations are applied. This can be done by adding new default version tables and overloading the manage.py migrate command. On import (and if required) EspressoDB tries to read the most recent information and fails if versions disagree.

Update related to the JOSS review process raised by @remram44.

openjournals/joss-reviews#2007

[ckoerber]

For this issue, the code development takes place on the feature-init-checks branch.

[ckoerber]

Closed with #48