Safer way to deal with API requests w/0 x-selected-project headers

[nathanielrindlaub]

As part of @alukach's typescript conversion, we tried aborting the user lookup (getUserInfo() in authorization.ts) when an x-selected-project header isn't present in a request. This solves a bunch of downstream TypeScript issues because many of our model methods expect there to be a project Id string for context.user['curr_project'] (which is what we set the value of the x-selected-project header to).

However, in at least one call – the initial getProjects query when the app loads and users have not yet selected a project - the frontend doesn't pass in a x-selected-project header in the request. There may be other calls that don't include that header as well. So we do need to figure out how to support context.user['curr_project'] being null.

Right now as a bandaid I reverted @alukach's change and set context.user['curr_project'] to and empty string if the header isn't present to make TypeScript happy, though that isn't exactly safe. If for some reason we accidentally called a method like this with an empty string as input:

const project = await ProjectModel.queryById(context.user['curr_project']);

the ProjectModel.queryById() method will fail with a NotFoundError('Project not found') error.

Maybe that's fine? Or maybe we should add a validation decorator (like we do with @roleCheck) to all of the model methods that require there to be a valid value for context.user['curr_project']?