Ensures #1858 works even after a refactor

We don't call this method anywhere. The CLI compiles without it, so let's delete it!

For some reason, until now, 404 errors received special treatment when running the sentry-cli files delete --all command. Therefore, if for whatever reason, the files could not be deleted due to a 404 error, the command would fail silently. The only indication that anything went wrong would be that the "All files deleted" message would not be printed.

Instead, it would make more sense to print the error message from the Sentry API and fail with a nonzero status, since the CLI has likely failed to accomplish what the user intended for it to accomplish when running the command.

Or, is there any reason why we need to keep the special logic for 404 errors around?

We removed Api::reset way back in #489. We should delete this comment that continues to reference Api::reset, since it is clearly inaccurate.

Most of the low-level Api functions are never called outside api.rs, yet we still label them as public functions. Let's make all the low-level Api functions only called in api.rs private, since we should anyways probably be using the high-level functions.

Previously, if users ran a Sentry CLI command that required authentication via an auth token, the CLI would make the API request, which would fail with a 403 error because the user did not provide any authentication. With this change, we locally validate that the auth token is present whenever it is required, and if it is missing, we do not perform the API request.

This change is implemented by creating a new struct called AuthenticatedApi in the api.rs file. The AuthenticatedApi holds a reference to an Api struct, whose config has been verified to have a non-None auth. An authenticated function has been added to the Api struct. This function ensures the Api it is called on has an auth, and if it does, it returns an Ok containing an AuthenticatedApi wrapping the &Api; otherwise, authenticated returns an error.

All high-level Api functions, which call API endpoints requiring authentication (most of the high-level Api functions require authentication), have been moved to AuthenticatedApi. Api now only implements the low-level API functions and the high-level functions that call endpoints which don't require token authentication. All calls to the moved high-level functions have been updated by adding an authenticated()? call before calling methods requiring authentication.

Fixes GH-1905

Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>

…ad (#1940)

… extensions (#1961)

Fixes GH-1959

…eport (#1962)

The distinction between "Scripts" and "Minified Scripts" is arbitrary. #1958 already eliminates the distinction for sourcemaps inject, and since the same code is also used to distinguish between files to output as "Scripts" and "Minified Scripts," merging #1958 already will cause the two sections to merge in the sourcemaps upload output.

However, with #1958, the two sections are merged as "Minified Scripts." If this PR is applied along with #1958 (which is my intention), it will cause the two sections to be merged as "Scripts." However, this PR is also completely independent of #1958 – applied alone, it will have the same effect of merging the "Minified Scripts" and "Scripts" sections of the sourcemaps upload report output under "Scripts."

The desired behavior of the command being tested is different from what the test specifies. This PR adds a comment to clarify the situation.

Ref #1963

…rce` for `sourcemaps inject` (#1958)

Until now, the sentry-cli sourcemaps inject command had only been injecting debug IDs into files that we had identified as being minified. However, the intended behavior for this command is for the command to inject debug IDs into all JS source files at the user-specified path; we should not distinguish between minified and non-minified files at all.

This PR implements the intended behavior.

Users who currently call the sourcemap inject command with a path containing files that should not be injected with debug IDs (such as a path containing both transpiled and source JS files) should update the path passed to only include transpiled JS files, or should use other command line arguments (e.g. --ignore) to exclude the source files from having debug IDs injected.

This PR is intended to provide a quick fix to implement the behavior. In the future, we plan to completely refactor and simplify the logic powering the sourcemaps inject command.

Fixes GH-1955

2.29.0 release was accepted before I was able to save these updates to the changelog. I plan to release a patch version containing the updated changelog. I have already updated the release on GitHub with these changes