[backend] Fix registrations created with postalcode1 = NULL

[pfortuna]

Some registrations are created with postalcode1=NULL.

27 March we had 12.2% of all registrations having postalcode1 = NULL

This is an urgent bug that must be fixed ASAP.

First prevent the API from accepting NULL postalcode1 returning an error. Then investigate what leads to that situation in the first place.

[pfortuna]

Might be related with:
Tech4covid19/trackovid19-web#278

[fernanri]

We have a single endpoint for updating user information which is used for several things (sending postal code, sending opt-in flags, so on). If we make the postal code mandatory at this endpoint we might end up breaking the UI. Therefore, my suggestion is to update the user's postal code when a new case is received, since the postal code is mandatory for the case endpoint.

[pfortuna]

We can do that. Don't call it "case" though to avoid confusion. We calling it "status update".

We also need to remove the property "Cases" being returned from /api/v1/user

[pfortuna]

During registration, after logging with Facebook, the user lands in the account settings page. Immediately, a row is inserted in the database with postalcode1 and postalcode2 = null.
If the user successfully submits his details and advances to the next page, a PUT is sent and immediately these columns are updated.

So, it seems that in these cases the user never successfully submits this form. Multiple reasons occur to me:

1. the user navigates away from the website out willingly
2. the user is jammed with some error and fails to understand how to get rid of them and eventually quits trying.

We should absolutely investigate if we have UX problems in this form, but we also consider only doing a first PUT after this screen, not before. Why are we doing a PUT with NULL values to postalcodeX ?
Should these columns even allow null ?
Can someone clarify?

[pfortuna]

3. the user has a small screen device and cannot scroll to fill all the mandatory fields

[pfortuna]

I'm moving this back to TODO as we need to see what happens when we deploy this fix:
Tech4covid19/trackovid19-web#302

In the meantime, I've created this issue to avoid creating these records with all null fields:
#145