[feat] Add API functionality to call Seer's test generation endpoint

[rohitvinnakota-codecov]

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 88.46154% with 6 lines in your changes missing coverage. Please review.

:white_check_mark: All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...rc/sentry/api/endpoints/ai_unit_test_generation.py	88.23%	6 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #78518      +/-   ##
==========================================
+ Coverage   78.08%   78.13%   +0.05%     
==========================================
  Files        7073     7090      +17     
  Lines      312058   312910     +852     
  Branches    50981    51133     +152     
==========================================
+ Hits       243669   244494     +825     
+ Misses      62035    62028       -7     
- Partials     6354     6388      +34     

[rohitvinnakota-codecov]

Thanks for the review @JoshFerge

The consumer of this API will be this class

Regarding security: The class above^ will do validation on the incoming request(which is fired by github). It verifies the signature of the request, as well as whether the user has write access to the repo they are specifying. This is the only route through which this API will be called.

Regarding custom errors: This API is called via an LLM interface, and the user expects some form of human readable response. The LLM basically takes the response from this API and converts it into a "chat message" format so I prefer to add some context here.

Regarding Repository object: Seer has a model defined for the Repo object as well and the params passed are validated by that model.

I switched to using keywords and a validator.

Please let me know if you have any questions, these changes are time sensitive so I'm always open to creating follow ups to clean things up.

[JoshFerge]

Thanks for the review @JoshFerge

The consumer of this API will be this class

Regarding security: The class above^ will do validation on the incoming request(which is fired by github). It verifies the signature of the request, as well as whether the user has write access to the repo they are specifying. This is the only route through which this API will be called.

Regarding custom errors: This API is called via an LLM interface, and the user expects some form of human readable response. The LLM basically takes the response from this API and converts it into a "chat message" format so I prefer to add some context here.

Regarding Repository object: Seer has a model defined for the Repo object as well and the params passed are validated by that model.

I switched to using keywords and a validator.

Please let me know if you have any questions, these changes are time sensitive so I'm always open to creating follow ups to clean things up.

do we have a spec for this anywhere? I'm confused on the flow of this endpoint being called

[rohitvinnakota-codecov]

Implementing in getsentry