Modularize Database

[confused-Techie]

Requirements

• Filling out the template is required.

• All new code requires tests to ensure against regressions.

  • However, if your PR contains zero code changes, feel free to select the checkmark below to indicate so.

• Have you ran tests against this code?

• This PR contains zero code changes.

Description of the Change

This PR takes it's cues from #199 and #224 by modularizing our Database.

Previously the database.js was a single large file containing all functions that interacted with the database. This PR breaks up every single function to it's own dedicated module, making each function easier to reason with, and quickly digest if needed.

Additionally, in the effort to ensure safe error returns to users, we had to validate each function on it's own, and manually enable safe returns for the Server Status Object on each function call, largely meaning this didn't happen, or has happened far too slow. With this new module format, we are able to declare constants on the database function call itself, allowing usage like seen below:

const pack = database.getPackageByName(name);

if (!pack.ok) {
  const sso = new context.sso();
  sso.safeReturn = database.getPackageByName.safe;
}

Notice how we call the function, but then we have a variable on the same location to check if this function has a safe return.

This new system will obviously be extremely helpful to manually validate the function itself for safe error returns, but it's entirely possible we can extend this system further, like seen with the successful object returns we use on each endpoint schema to test the object schema we get back, we can do the same on database calls, further ensuring the in memory objects we work with are always properly formed along the entire chain.

Both usages of this new format are currently not used, but this lays the groundwork for it to happen, while this PR focuses soley on moving the logic from one large file to many smaller files.