Clarify study/dataset lookup responses across all EDA services

[ryanrdoherty]

Currently we are a little inconsistent with responses 404 vs 403 when requesting dataset access for user studies. Most services request a perms object using a study ID and then when parsing the /permissions response, throw 403 if the study is missing (meaning either user cannot see it (does not have access) OR it does not exist).

Meanwhile, the EDA user service, when checking a dataset to determine if an analysis can be imported to a user, uses dataset ID to hit a different endpoint in the dataset access service. This endpoint uses the same query as the permissions endpoint to check user perms, BUT if the dataset is not found in those the user has access to, it does an extra check to see if it exists. Thus it can determine whether user cannot see the dataset because it doesn't exist or because the user simply doesn't have access.

It would be nice for all services to be able to make this determination, but doing so efficiently (do not want to do the double query every time) is non-trivial. This issue covers that work, plus the migration of the dataset access client in EdaCommon to call whatever efficient new endpoints are created by this issue.

[aurreco-uga]

the current UX is that the user owning the UD, when trying to go to EDA, gets a "page not found". And we do not know if this is because the study does not exist in the service app DB, or because the user does not have permissions (a guest or someone not owning the UD) The way to know is check the client permissions endpoint***

This is also an issue in qa sites with studies being reloaded ... they might be loaded but the table apidbtuning.STUDYIDDATASETID does not contain the mapping to a DS_xxxxx.. client shows 404 as response to a nonsensical 403.. oh well..