Squash lava_scheduler_app migrations 0001-0026 to fix example.com worker always being created and improve lava-health password locking

Squash lava_scheduler_app migrations 0001-0026 to fix example.com worker always being created and improve lava-health password locking

Closes #640

The migrations from 0004 to 0026 contained no RunPython stages therefore can be easily squashed. Migration 0027 was added with commit ae4d4776 in May 2017. Unless you never upgraded LAVA from 2017 you should have no issues upgrading to next LAVA version.

The migration 0003_populate_master_node always created an "example.com" worker even though it is no longer required to run LAVA.

This requires adjusting the unit tests that assumed the "example.com" worker is always present.

Also improve how lava-health password is locked. Before it would be set to UUID version 4 random value. However, RFC4122 explicitly states not expect UUID to be hard to guess.

https://www.rfc-editor.org/rfc/rfc4122#section-6

Instead use the Django's unusable password which makes it impossible to log in or reset password.

https://docs.djangoproject.com/en/2.2/ref/contrib/auth/#django.contrib.auth.models.User.set_unusable_password

Unfortunately during migrations the set_unusable_password is not available because of historical models.

https://code.djangoproject.com/ticket/26445

Instead do what set_unusable_password method does. Call make_password with None.

https://github.com/django/django/blob/08306bad57761b5eb176894649ac7d4e735c52dd/django/contrib/auth/base_user.py#L118