Refactor GitHub Interactions

Alright, so long time coming, but I'm soon planning to do a full refactor on the git module, and how we interact with GitHub as a whole.

Since nearly all of our publishing issues stem from this module and the way we use it.

Plus now we are currently exporting nearly every intended to be internal function into the package_handler causing a mess of error checking, which against our MO requires extra internal knowledge of how this module works, and goes against what one would assume from the rest of our error checking on how to error check against it.

So with all that said, I want to refactor to solve the above issues, but thought it would be a good idea to plan this out in an open space, to get some help on identifying our weak points when it comes to this package and it's usage, to ideally get everything covered all at once. So below I will lay out some of the goals, and challenges we currently face that can ideally be resolved.

We eventually will want to support more than just GitHub. Ideally the git module can be the platform agnostic implementation, that will then use whatever needed service to interact with packages for us in general. Being able to support every other platform we want. This does likely mean we will need to be passing the full Package Object to this package during interactions, or at the very least now directly interacting with our custom repository key of the pakage.data object to identify what platform is in use.
We need to support GitHub repo renames every way we can. For most git functions this is easy, since GitHub will automatically redirect requests from the old name to the new one. The point where this becomes and issue, and is the most important is git.ownership() since that function checks the owner/repo combo exactly using our package data, if the repo is renamed, it'll never be able to determine ownership, as the name we have is old. This has a PR currently open to fix this only on the version publish endpoint, but this needs to be working everywhere, which will likely require a change in git itself.
It's a wishlist item, but I'd love to try and use GitHub NPM modules over interacting directly with the API. Allows us to abstract more away from this, and makes error handling much easier since we don't have to check status codes at all. But does mean we will likely use more memory, since we will have to declare the module over and over with new credentials of each user request. So we will have to have sufficient destruction of the declared modules after use.

That's all I've got for now, but please if there's anything I've missed add it below so we can try to get all this stuff in one big swoop like I'll be attempting later this week

Below are some notes I took quickly and want to save for further reference here.

The notes are the quick breakdown of our interactions with VCS's. In an attempt to find a way to streamline them with the refactor

Current Workflows:

postPackages

auth.verifyAuth
params.repository validity
params.repository Validity as a repo
utils.isPackageNamedBanned
database.getPackageByName Does it exist check
git.ownership
git.createPackage
database.insertNewPackage
database.getPackageByName
utils.constructPackageObjectFull
return

deletePackagesName

auth.verifyAuth
database.getPackageByName
git.ownership
database.removePackageByName
return

postPackagesStar

auth.verifyAuth
database.updateIncrementStar
database.getPackageByName
utils.constructPackageObjectFull
return

deletePackageStar

auth.verifyAuth
database.updateDecrementStar
return

postPackagesVersion

auth.verifyAuth
database.getPackageByName
utils.getOwnerRepoFromPackage
git.getPackageJSON
git.getRepoReadMe
git.metadataAppendTarballInfo
git.ownership
database.insertNewPackageVersion
return

deletePackageVersion

database.getPackageByName
git.ownership
database.removePackageVersion
return

postPackagesEventUninstall

auth.verifyAuth
database.getPackageByName
database.updatePackageDecrementDownloadByName
return

pulsar-edit / package-backend