Refactor Sentry::Client error handling
Currently, Sentry::Client raises an exception when an error occurs (like missing keys in Sentry response or non-200 status in Sentry response).
Since reactive cache is used in the ProjectErrorTrackingSetting model to call Sentry::Client, exceptions need to be caught in the ProjectErrorTrackingSetting model. Once the exception is caught, an error object needs to be passed to the caller (ErrorTracking::ListIssues and ErrorTracking::ListProjects services) so that they have enough information to decide what response should be returned to the FE.
This issue is to refactor how success and error information flows from Sentry::Client to ProjectErrorTrackingSetting and then to ErrorTracking::ListIssuesService and ErrorTracking::ListProjectsService.