Merge rust-bitcoin/rust-bitcoin#2773: reduce two-ACK requirement to one-ACK requirement

f3d364ef1d reduce two-ACK requirement to one-ACK requirement (Andrew Poelstra)

Pull request description:

  For the last few months it has only been myself and tcharding working on this project actively. Prior to that we had Kixunil as well, which allowed us to move forward requiring two ACKs on every PR (though it put a minimum 24-hour delay on everything since we are pairwise 8 hours separated from each other in timezones).

  The other listed maintainers, especially Sanket and Matt, are intermittently available, which is awesome but insufficient to get large refactors or long-term work through.

  We have increasingly depended on the "one-ACK carveout", an ever-increasing list of exceptions to our two-ACK rule. Most silly, one exception is that if something stays open for two weeks, we don't need the second ACK. So the result is a "one ACK plus 2 weeks" policy which is grating and demoralizing.

  Meanwhile, we are not finished our crate-smashing project or our API overhaul, and we want to continue moving at a fast rate. (Though of course, we will take breakage seriously; we do not want to make gratuitous changes or changes that replace previous changes, and the changes we *do* make we will do our damnedest to do via a year-long deprecation cycle. And we welcome suggestions to improve our policy or process on this front. But requiring extra maintainers/reviewers has not been helpful for us.)

  I'll let this PR sit open for 7 days (til Wed May 22) to accumulate ACKs or NACKs, and assuming no strong opposition, will merge it.

ACKs for top commit:
  sanket1729:
    ACK f3d364ef1d

Tree-SHA512: 6d1ea41ce79b038304c59d574b239fc855cc178dc61b4dd8e20dc9e0493278df339950a7604592dd20d7b25c8c56f6d4b5c13b103771a8b920ec10d4050578ae

CONTRIBUTING.md

@@ -136,7 +136,7 @@ grammar fixes.
 
 Pull request merge requirements:
 - all CI test should pass,
-- at least two "accepts"/ACKs from the repository maintainers (see "refactor carve-out").
+- at least one "accepts"/ACKs from the repository maintainers
 - no reasonable "rejects"/NACKs from anybody who reviewed the code.
 
 Current list of the project maintainers:
@@ -150,38 +150,6 @@ Current list of the project maintainers:
 - [Riccardo Casatta](https://github.com/RCasatta)
 - [Tobin Harding](https://github.com/tcharding)
 
-#### One ACK carve-out
-
-The repository is going through heavy refactoring and "trivial" API redesign
-(eg, rename `Foo::empty` to `Foo::new`) as we push towards API stabilization. As
-such reviewers are either bored or overloaded with notifications, hence we have
-created a carve out to the 2-ACK rule.
-
-We reserve the right to merge PRs with a single ACK [0], at any time, if they match
-any of the following conditions:
-
-0. PR has a single ACK and has sat open for at least two weeks with no comments,
-   questions, or NACKs.
-1. PR only touches CI i.e, only changes any of the test scripts and/or
-   stuff in `.github/workflows`.
-2. Non-content changing documentation fixes i.e., grammar/typos, spelling, full
-   stops, capital letters. Any change with more substance must still get two
-   ACKs.
-3. Code moves that do not change the API e.g., moving error types to a private
-   submodule and re-exporting them from the original module. Must not include
-   any code changes except to import paths. Requires absolutely no change to the
-   public API.
-4. PR has previously had two ACKs, had minimal changes, and gets a single ACK
-   from Andrew. This call is subjective, gives extra privileges, but also
-   requires extra responsibility/accountability (including running a bunch
-   of local CI checks before merging) [1].
-
-
-
-[0] - Obviously author and ACK'er must not be the same person.
-[1] - The aim is to reduce the burden of re-ACK'ing trivial changes and also
-      alleviate the problem of devs spread around the world in different timezones.
-
 #### Backporting
 
 We maintain release branches (e.g. `0.32.x` for the `v0.32` releases).