Move db from internal to pkg

[rdimitrov]

Summary

The following PR moves db from internal to pkg

Change Type

Mark the type of change your PR introduces:

• Bug fix (resolves an issue without affecting existing features)
• Feature (adds new functionality without breaking changes)
• Breaking change (may impact existing functionalities or require documentation updates)
• Documentation (updates or additions to documentation)
• Refactoring or test improvements (no bug fixes or new functionality)

Testing

Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.

Review Checklist:

• Reviewed my own code for quality and clarity.
• Added comments to complex or tricky code sections.
• Updated any affected documentation.
• Included tests that validate the fix or feature.
• Checked that related changes are merged.

[coveralls]

Pull Request Test Coverage Report for Build 11519330010

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 52.948%

---

Totals
Change from base Build 11518605954:	0.0%
Covered Lines:	13298
Relevant Lines:	25115

---

💛 - Coveralls

[evankanderson]

What portion of /internal/db are you hoping to access? I'm split on this -- on one hand, having additional tools not "slip" the query and schema seems useful. On the other hand, I worry about introducing a bunch of SQL for tools in mindersec/minder which isn't actually used in that codebase.

On the gripping hand, I worry about queries like SELECT * FROM ... getting broken by a schema changed applied by the push process of another tool. This is actually something that we could suffer from today during a push -- can you check and see what the effect is if you add a migration and then run some pre-migration sqlc code that is defined using SELECT * into a struct? e.g.

--- name: GetArtifactByID :one
SELECT * FROM artifacts
WHERE artifacts.id = $1 AND artifacts.project_id = $2;

ALTER TABLE artifacts
  ADD COLUMN a_test IF NOT EXISTS BOOLEAN NOT NULL DEFAULT TRUE;

// What happens if I built a tool before the migration was defined, and then run the query after the migration has been run on the database?

[rdimitrov]

Closing this as we are going to take another approach in a follow up PR