fix(server): permit null values in devices response

[philbooth]

Fixes #1123 but depends on changes in mozilla/fxa-auth-db-mysql#117 so do not merge until after that PR has been accepted.

This issue was caused by my misunderstanding of Joi's optional(), which doesn't permit null values. It was exacerbated by yet another gaping hole in my test coverage, this time in fxa-auth-db-mysql, which meant the memory backend and the MySQL backend were behaving differently with regards to the initialisation of missing fields in the devices table.

And then I stupidly to forgot to test device registration against the MySQL backend, so the aforementioned discrepancy masked this bug until @jrgm found it when he deployed train 50. Apologies @jrgm (and everybody else).

I've updated npm-shrinkwrap.json here for the purposes of making travis pass, but it will need to be updated properly when the db change is in master.

[philbooth]

Just to add, in case it isn't clear: the db change doesn't touch any production code. I don't know where this leaves things in terms of trains but, if it is decided to patch train 50 with this fix, there's no need to also patch the db.

[rfk]

And then I forgot to test device registration against the MySQL backend

We shouldn't have to explicitly remember these things. Is there a problem with our travis config on this repo?

[rfk]

I filed #1125 to remind us to take a look at why travis didn't catch this; code here looks good, r+

[rfk]

@philbooth I wonder if all this fragility is the reason we had disabled response schema validation on some routes in the past...

[philbooth]

I wonder if all this fragility is the reason we had disabled response schema validation on some routes in the past.

Yeah, I can believe that. Fwiw, I still like the design-by-contractness of it and it was only because of some missing test coverage that the fragility was able to be an issue.