simplify the release checklist

[marten-seemann]

If we're cutting more frequent and smaller releases, we need to cut down on the overhead a release is creating.
Most of these changes just reflect what we've been doing (or rather, what we've not been doing) in the past.

[BigLep]

General comments:

1. Can we have a "breaking changes" section so that is clearly called out for users?
2. My understanding is that we cut PRs against Kubo/Lotus because their CI (e.g., Kubo sharness tests) help catch issues in libp2p before release. Is that right? I agree libp2p team shouldn't be doing the work to get go-libp2p features exposed in Kubo unless it's critical for libp2p's success (e.g., AutoRelay / Flare). Anyways, I think we should document/capture the guiding principles here so it's clear for new team members.

The goal we want to have here is that no tribal knowledge should be execute it. We should be able to drop other/new team members in and they should be able to execute it as well.

[MarcoPolo]

My understanding is that we cut PRs against Kubo/Lotus because their CI (e.g., Kubo sharness tests) help catch issues in libp2p before release.

Yeah I think that's right. But I think that's an indicator that our own testing coverage isn't good enough. I know I've caught bugs I've written because of Kubo sharness. Maybe we keep the "Kubo CI passes" pre-release check if the changes are significant (major release) until we feel more confident in our own test suite?