Fix server error upon processing user with revoked github token

[ConorBobbleHat]

Fixes the root cause behind #782.

Right now, GitHubUser.details uses the user's authentication token to fetch their own details. In doing so, it doesn't check if the token's been revoked by its owner, and errors out if it has.

As all the details we're looking for are publicly available, this PR switches to fetching the user's details sans an authentication token. Insofar as I can tell, this is the only such place we're using an auth token unnecessarily.

This is a little bit of a band-aid fix because it ignores the fact there are still other ways fetching a user's information can fail (although they're rarer still). Happy for greater error checking to be included in this PR, or to leave it as a future issue.

[bates64]

As all the details we're looking for are publicly available

Is this certainly the case for things like email? Or does the response differ a bit
I don't think we use it but just so we know for future

[ConorBobbleHat]

From https://docs.github.com/en/rest/users/users?apiVersion=2022-11-28#get-a-user, the /users/<username> endpoint

Provides publicly available information about someone with a GitHub account.

The waters are muddied slightly by the fact we're using an undocumented version of the endpoint (/user/<user id>) instead, but - at least as I write this - they resolve to exactly the same response.

[ConorBobbleHat]

in the process of looking that up, I did stumble across this: https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting

For unauthenticated requests, the rate limit allows for up to 60 requests per hour. Unauthenticated requests are associated with the originating IP address, and not the person making requests.

That would be down from 15,000 an hour per user for a token-authenticated request - this one may need to go back to the drawing board for a bit

[mkst]

It's a rare scenario, but it's already happened once - so I say lgtm :)

[bates64]

Looks good. Might be worth changing __str__ to not call details given that its more liable to fail with a timeout exception now. It was stupid of me to have __str__ possibly make a network request in the first place tbh.

decomp.me/backend/coreapp/models/github.py

Lines 95 to 96 in 4106e8c

	def __str__(self) -> str:
	return "@" + self.details().login

[ethteck]

I'm cool with merging this after that last comment is addressed

[bates64]

I think itd be fine to just report the user id

[bates64]

Good to merge once tests pass ✅

[ethteck]

The 8 tests that failed are the new compilers which will be fixed in #800 . merging