Remove will_wake calls

[akoshelev]

We used will_wake in correctness checks to make sure we don't hang the future/stream forever if a wrong waker is used, but the contract for this function is best-effort and it started generating more and more false positives.

The recent one, found by @aleiserson, is inside rust-lang (rust-lang/rust#119863), so it is very hard to get around.

We don't have a good replacement for this check unless we implement our own waker, but it is probably too much for now

[codecov]

Codecov Report

Attention: Patch coverage is 95.65217% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 90.59%. Comparing base (20c89ed) to head (56959cf).

Files	Patch %	Lines
...pa-core/src/helpers/transport/stream/collection.rs	90.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1037   +/-   ##
=======================================
  Coverage   90.58%   90.59%           
=======================================
  Files         173      173           
  Lines       26089    26082    -7     
=======================================
- Hits        23632    23628    -4     
+ Misses       2457     2454    -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[martinthomson]

That's unfortunate. I guess the real expectation is that we maintain multiple wakers. That seems like a language feature that is really a bug: in that it imposes (unreasonable) costs on those using the API.

[akoshelev]

That's unfortunate. I guess the real expectation is that we maintain multiple wakers. That seems like a language feature that is really a bug: in that it imposes (unreasonable) costs on those using the API.

yea I am not sure I understand the motivation for making it best-effort, probably some hard constraint on the scheduling side. Or it was never designed to avoid false negatives, they were really only interested in true positives.

[akoshelev]

related to #1036

[andyleiserson]

There is also a comment around line 58 of ordering_sender.rs "here used to be a check that new waker will wake the same task", that can probably be deleted. (This PR and the linked issue seem like sufficient documentation of the demise of will_wake checks.)

[akoshelev]

There is also a comment around line 58 of ordering_sender.rs "here used to be a check that new waker will wake the same task", that can probably be deleted. (This PR and the linked issue seem like sufficient documentation of the demise of will_wake checks.)

yea I was contemplating about it and was really on the fence about that one. Now the balance is changed so I'll remove it