chore(sentry apps): Improve Sentry App Errors

[Christinarlong]

Introduces two classes to represent Sentry App exceptions:
SentryAppError should be used to represent client side errors like failed validation. For the webhook, these should not be sent to the integrator.
SentryAppIntegratorError is used to represent errors between Sentry & the integrator, i.e connection failed, integrator response is incorrect etc. These should be sent to the integrator for the webhook.

For this PR, we want to start wrapping errors in the SentryApp flows with these distinctions. And then in the endpoints we want to catch these two specific errors and return the error message. More info here in notion

This PR is kinda two PRs in one, because I wanted to refactor the alert rule creation flow for Sentry Apps. Currently creating an alert rule for sentry apps has a really weird flow where we don't raise errors until very late.

Context for Alert Rule Sentry App creation: Notion doc

[codecov]

Codecov Report

Attention: Patch coverage is 89.62963% with 14 lines in your changes missing coverage. Please review.

✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/sentry/sentry_apps/utils/alert_rule_action.py	91.52%	5 Missing ⚠️
...s/external_requests/alert_rule_action_requester.py	72.72%	3 Missing ⚠️
...ps/api/endpoints/installation_external_requests.py	60.00%	2 Missing ⚠️
src/sentry/sentry_apps/services/app/impl.py	75.00%	2 Missing ⚠️
...rc/sentry/sentry_apps/alert_rule_action_creator.py	88.88%	1 Missing ⚠️
...try_apps/external_requests/issue_link_requester.py	75.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #81877      +/-   ##
==========================================
+ Coverage   80.33%   80.60%   +0.27%     
==========================================
  Files        7272     7259      -13     
  Lines      321230   324846    +3616     
  Branches    20941    20793     -148     
==========================================
+ Hits       258051   261857    +3806     
+ Misses      62784    62590     -194     
- Partials      395      399       +4     

To fix the problem, we should ensure that detailed error information is logged on the server while returning a generic error message to the user. This can be achieved by logging the exception details and returning a user-friendly error message in the response.

• Modify the code to log the exception details using the logger and return a generic error message to the user.
• Ensure that the logging captures sufficient information for debugging purposes without exposing sensitive details to the end user.

To fix the problem, we need to ensure that the exception messages returned to the user do not contain sensitive information. Instead, we should log the detailed error message on the server and return a generic error message to the user. This can be achieved by modifying the exception handling blocks to log the error and return a generic message.

To fix the problem, we need to ensure that the exception messages returned to the user do not contain sensitive information. Instead, we should log the detailed exception information and return a generic error message to the user. This can be achieved by modifying the exception handling blocks to log the exception and return a generic error message.

[getsantry]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you remove the label Waiting for: Community, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀