fix(crates.io): Decorate add_owners error for missing team responses

[calavera]

What does this PR try to resolve?

GitHub might return a generic error if the user has not configured their permissions correctly to access a team. In this case, the add_owners function decorates the response error to include a link to the documentation.

Fixes #11505

How should we test and review this PR?

I didn't see any integration test that exercises this code, but let me know if I missed where the crates api is tested.
This is what I did to test the code:

1. Compile cargo
2. Try to add a team that doesn't exist in GitHub to a crate that you have access to.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @weihanglo (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[arlosi]

Thanks for this!

I wonder if this could be done on the crates.io side instead. Then we wouldn't need to special-case this in Cargo, and older versions of Cargo would also get the improved error message.

Here's where the error is coming from in crates.io.

[weihanglo]

Oh ya agree with arlosi on in that regard. I didn't though of that.

Actually in #11505 I was expecting to see documentation improvement with some screenshots, as JT described. The error message enhancement is just a nice-to-have.

Thanks for your contribution anyway!

[calavera]

I wonder if this could be done on the crates.io side instead.

There are a few reasons why I didn't make the change in crates.io:

1. I don't know how older versions of Cargo display this. It might be fine, or it might break it. I would have to test with all versions of Cargo.
2. I don't know which other clients might consume this API. I don't want to break all expectations for other crates.io clients.
3. The documentation link is specific to Cargo. I don't know if there is a precedence of crates.io returning links to the Cargo docs, but it doesn't sound right to me.

[arlosi]

I don't know how older versions of Cargo display this. It might be fine, or it might break it. I would have to test with all versions of Cargo.

I agree, it would be a good idea verify that this didn't break old versions. I don't think we'd need to test every release, however.

I don't know which other clients might consume this API. I don't want to break all expectations for other crates.io clients.

I feel like the change would be acceptable. It's just changing the error message text. Cargo is the only supported client of crates.io. Of course, we'd need to get the crates.io team approval. I don't speak for them.

The documentation link is specific to Cargo. I don't know if there is a precedence of crates.io returning links to the Cargo docs, but it doesn't sound right to me.

Pretty much all of the crates.io documentation is in the Cargo docs. Go to https://crates.io and click "Getting Started" and you're taken to Cargo docs.

[arlosi]

@calavera the implementation in the PR looks good, but I think I'd rather this error came from crates.io, rather than making a special case for it here in Cargo.

Would you be interested in making the documentation updates that @weihanglo suggested here? Or possibly even making a PR to crates.io to improve the error message there?

[calavera]

I'll take a look.

[calavera]

I'll open a new PR with doc updates. No need to keep this code around if it won't be merged.