Standardize rule endpoint client identification

[TheJeffreyKuo]

Changes

Standardized client identification across all rule endpoints by moving client_id into the URL path. Previously add_rule and delete_rule pulled it from a Basic Auth header while subscribe_rules and unsubscribe_rules pulled it from the JSON body. Instead, all rule endpoint reads client_id now. The frontend API layer was updated to match this.

Checklist

It can be helpful to check the Checks and Files changed tabs.
Please review the contributor guide and reach out to your Tech Lead if anything is unclear.
Please request reviewers and ping on slack only after you've gone through this whole checklist.

• All commits are tagged with the ticket number
• No linting errors / newline at end of file warnings
• All code follows repository-configured prettier formatting
• No merge conflicts
• All checks passing
• Screenshots of UI changes (see Screenshots section)
• Remove any non-applicable sections of this template
• Assign the PR to yourself
• No package-lock.json changes (unless dependencies have changed)
• Request reviewers & ping on Slack
• PR is linked to the ticket (fill in the closes line below)

Closes #561

[bracyw]

actually looking at this I think it would be better to add the client-id as a Header, instead of in the url param because rule_id forcing you to add the client_id after the "/rules/ " which makes querying possible conflict based on client_id. (so disregard the ticket recommendation of path param or body)
TLDR: let's pivot to Header based client-id

[bracyw]

actually looking at this I think it would be better to add the client-id as a Header, instead of in the url param because rule_id forcing you to add the client_id after the "/rules/ " which makes querying possible conflict based on client_id. (so disregard the ticket recommendation of path param or body) TLDR: let's pivot to Header based client-id

You can check rust axum docs on how to write the backend code for this.

[bracyw]

A few TODO's for ticket creation. But LGTM to merge!

[bracyw]

For another ticket, task we can make: transitioning to a slightly more abstracted tool than fetch, or further abstracting headers into multiple lambdas or a recursive lambda setup... something along those lines.

[bracyw]

in the future a type like this could be good, but rn no abstraction needed.

[bracyw]

a follow up ticket. I didn't really investigate the quality of toggle subscriptions when initially made. I will make this a ticket.

[bracyw]

can you link to rust docs on this. like to keep everything more complex to the docs.