What?

Updating the Request entity to accommodate upcoming functionality in the process step:

• New RequestState values - processing once the processing step has started, and superseded for requests that will be skipped in favor of building a newer one
• BuildStrategy/BaseURI fields which will get populated by the process process for downstream use during builds
• Since request IDs are minted in order by ingest, I realized it's a bit redundant to store a separate sequence ID in the DB. Instead, define a CompareRequestID function for cases that require ID comparison, and converge to just storing the ID.

Why?

Implementing behavior in https://github.com/uber/submitqueue/blob/main/doc/rfc/stovepipe/steps/process.md - which introduces two new outcome states and includes logic to determine the build strategy for a request.

Test Plan

• Unit tests
• Subsequent changes will pull this logic together into an end to end flow