feat(cdp): spike out new REST API in property-defs-rs

[eli-r-ph]

Problem

CDP team aims to replace the property definitions API in the Django monolith with a new API implemented in the new property-defs-rs service.

Changes

The PR scaffolds out the basic API, including new axum GET route, request parameter extraction, and a pair of queries that for the core of the project-scoped property definitions APIs in the Django service.

There's lots more to do here, but I want to land this first iteration before it gets too large. TODOs include:

• Finish populating response object from query results in more axum/serde_json friendly way
• Sanity check API behavior and query generation in local dev env
• Implement the rest of the prop def APIs and point-update CRUD handlers
• Write lots of unit tests

How did you test this code?

Locally, so far (see above)

[greptile-apps]

PR Summary

This PR introduces a new REST API in the property-defs-rs service to replace Django's property definitions API, implementing query building, routing, and constants management.

• Critical bug in routing.rs: gen_url function hardcodes "new_value" instead of using actual new_offset value for pagination
• Missing error handling in routing.rs: URI unwrapping can panic when scheme/authority are missing
• Incorrect type in routing.rs: is_seen_on_filtered_events defined as String but used as boolean
• Syntax error in Cargo.toml: url.workspace = true should be url = { workspace = true }
• Empty results array in routing.rs: Query results not being populated into PropDefResponse

_{8 file(s) reviewed, 10 comment(s)
Edit PR Review Bot Settings | Greptile}

[eli-r-ph]

👋 added you as a reviewer @oliverb123 🙇 my goal is to (among other things) do a quick walkthrough of this iteration of the new API tomorrow at our huddle, get anything that concerns you straightened out, then hopefully land it and iterate in follow-on PRs from there.

At this point the API/query plumbing should be a no-op, so I assume this plan is safe 🤞 ...but I'm just getting back into Rust now, so feel free to push back on this idea if you see something ghastly!

[eli-r-ph]

👋 @oliverb123 FYI for your review pass on this:

• I updated the PR to reflect all but one of the changes we discussed
• Some of them I just made the initial change and will iterate further after this is landed
• In one case (moving to pass QueryBuilders around by mutable ref) I hit the same trouble as last time around, so I didn't push that change...
  • Here's a gist of what I sketched out on the branch
  • With that patch, I got the same error[E0499]: cannot borrow '*qb' as mutable more than once at a time due to the 'a lifetime, which I've sidestepped so far by passing ownership of the qb in and out of each helper function instead 🤷

☝️ I'm fine iterating on that later as it isn't blocking anything, but I'm sure I'm missing something conceptual (and perhaps simple?) about the lifetimes of the builder vs. parameters I'm binding to it right now

Thanks again!