Add database table and methods for profile selectors

[jhrozek]

Summary

• Add the selectors table
• Add DB methods for selector management

So far just adds the table and the methods and their tests. These will be used in later PRs.

Fixes #3720

Change Type

• 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

with the unit tests

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.

[jhrozek]

I really wanted to add an upsert, but since the only column to conflict on would be the ID, the upsert would be able to add a zero UUID. I tried working around that with a little more SQL code, like:

INSERT INTO profile_selectors (id, profile_id, entity, selector, comment)
VALUES (
   CASE WHEN $1::uuid = '00000000-0000-0000-0000-000000000000' THEN gen_random_uuid() ELSE $1::uuid END,
   $2::uuid, $3, $4, $5
)
ON CONFLICT (id) DO UPDATE
    SET profile_id = $2::uuid,
        entity = $3,
        selector = $4,
        comment = $5
RETURNING id, profile_id, entity, selector, comment;

but that breaks sqlc - it wasn't able to infer the type of $1 and generated parameters with a column named Column_1 and type interface{}. Trying to use sqlc.arg(id) instead of $1 didn't work either, because sqlc apparently requires that all parameters be used in the query.

So I went with just an update now and will handle the upsert case in the code instead.

[evankanderson]

If profile_id is not unique, I'm not sure what the upsert would look like unless you always have the UUID already created (e.g. client-side generation). profile_id is not marked as unique at the moment, so I'm not sure that upsert is particularly useful -- you'll know whether you have an existing UUID or not, and can switch between the insert and update pretty easily.

[coveralls]

coverage: 52.478% (-0.009%) from 52.487%
when pulling aa40ff6 on jhrozek:selectors
into cdb5ae7 on stacklok:main.

[evankanderson]

LGTM.

[evankanderson]

If profile_id is not unique, I'm not sure what the upsert would look like unless you always have the UUID already created (e.g. client-side generation). profile_id is not marked as unique at the moment, so I'm not sure that upsert is particularly useful -- you'll know whether you have an existing UUID or not, and can switch between the insert and update pretty easily.