userViewById: add whether we can view/edit his personnal info

fixes #1090

Add personal_info_access_approval_to_current_user in the response, which is the max value among the groups for which both the current user is implicitly manager of, and the user requested is descendant of.

Notes:

The field is not present if the current user is not a manager of the user, to make it consistent with the other fields.
The userViewByLogin service is affected in the same way (/users/by-login/{login}), as the same code serves the two services

Implementation

We already get the list of groups of which the current-user is a manager and of which the user is a descendant of (for the field ancestors_current_user_is_manager_of). So to avoid doing another query for this, the values of require_personal_info_access_approval were added in the select of the existing query.

Then, with the result of the query, we fill the groups information and we compute the max.

Another way of doing would have been to create a query just for it, but since it requires to check the same groups as ancestors_current_user_is_manager_of, we would have done almost the same work twice.

Query index

Only added a field in the select, so there's no need for a new index.

Review

Probably easier all at once because there are a few refactoring to make the code clearer.

France-ioi / AlgoreaBackend