ci: disable dependabot cargo updates

[cpu]

Until we have a better sense of how to handle the update PRs it produces let's turn this off for now. I think I was premature in enabling it. Inspired by discussion in this PR thread.

[complexspaces]

Until we have a better sense of how to handle the update PRs it produces let's turn this off for now.

Did you want to discuss that in this PR or would it be better to open a followup issue where the topic can happen? I don't mind either way.

[cpu]

Did you want to discuss that in this PR

WFM!

I think there's two topics:

1. whether it's worth maintaining Cargo.lock updates for compatible updates. We do it in the other Rustls repos, but I don't think I can articulate a very meaningful argument for why we should do it here.
2. how they should be reviewed (edit: and how many reviews should there be before merge). In the other Rustls repos we don't (at least as I understand things) do more than a cursory review of the update. When we were using Dependabot I would review the updates in https://diff.rs and pay particular attention to things like build.rs updates, but for large deps like aws-lc-rs/aws-lc-sys I certainly don't review every changed line. I also haven't been keeping up with that practice since switching to Renovate. How are other folks handling these?

[djc]

I generally scroll through the Cargo.lock changes looking for any new dependencies, but I don't look at the actual changes made in semver-compatible upstream versions.

[djc]

Should we also disable this for github-actions?

[djc]

A potential third topic for discussion: being more explicit about ownership. So far I think we've mostly deferred to @complexspaces on any half-way nuanced changes, but the downside is that @complexspaces has pretty limited bandwidth certainly compared to the other rustls org maintainers. Maybe we can get to a tweaked proposed governance model?

[cpu]

Should we also disable this for github-actions?

These seem infrequent enough that I was OK leaving it on, but happy to revisit.

[worldwise001]

Hey folks, @complexspaces directly reports to me currently (I'm director of seceng at 1Password); I don't feel particularly strongly one way or another as to what the governance model of this library/project should look like, but I am open to discussion as to how/where we can adjust or increase 1Password involvement/support. :)

Let's bring this discussion into another issue?

[djc]

Hey folks, @complexspaces directly reports to me currently (I'm director of seceng at 1Password); I don't feel particularly strongly one way or another as to what the governance model of this library/project should look like, but I am open to discussion as to how/where we can adjust or increase 1Password involvement/support. :)

Let's bring this discussion into another issue?

Opened #125 for this.

[complexspaces]

Should we also disable this for github-actions?

These seem infrequent enough that I was OK leaving it on, but happy to revisit.

I'm also in favor of leaving GHA updates enabled since they are less frequent and less work to review.

I generally scroll through the Cargo.lock changes looking for any new dependencies, but I don't look at the actual changes made in semver-compatible upstream versions.

This is what I do as well.

Overall, I'm in favor of what is currently being proposed in this PR's branch contents as it creates less noise and review burden over very small changesets.