github: make the LFS readable for repos that are public

[vit-zikmund]

This has come out of a brainstorm in #166 (comment) and as the issue's original topic will be covered by PR #175, this is being separated out not to get lost in a closed issue.

For the record, checking if a repo is readable would be done with the Get a repository API call and checking the visibility field for public or internal.
public is simply readable to the world, internal only to members of GitHub Enterprise organization. I assume the latter wouldn't be visible at all for a user outside of the enterprise organization, so a 40x response is a good marker the repo is not readable.

This will now need to be thought through for both the personal access tokens and app installation tokens.

[vit-zikmund]

FYI @SkyDev125, yet another opportunity waiting for your grasp! 😉

[vit-zikmund]

Here are some more thoughts:

• The auth plugin's job is to scramble all valid permissions for the identity behind the provided token. Therefore, the check for public repo access evaluation should be done as a last resort, after all existing permission-evaluating means fail.
• As each API call to GitHub is expensive (and potentially limited), this should be cached (outside of any identity cache, just a map of public repos).
• visible internal repos can't be considered generally public, but when successfully listed, the read/read_meta permission should be added to the identity's permission.
• public repos don't need any token to get listed, so we should make sure not to require internal resolving to any identity. As the giftless code assumes there's always some identity, in case the token is invalid or missing, we should provide some bogus identity. However such identity can't serve as a catch-all fallback for misauthenticated calls. Therefore we need to cache the public repos independently of any identity.
• TODO think about how this all applies to app installation tokens.

[refringe]

What I've done as a workaround is spin up two docker containers, one for lfs-write.site.com and another for lfs-read.site.com. They both point to the same host data directory. The write container simply has write access to the host path, and the read container only has read access. The write is secured by github auth, and the read is public. It's been working very well for our use case within the Github ecosystem.