Fix memory leak/growth when creating many runtimes

[ipetkov]

• Rather than using a vector of mpsc channels to dispatch received signals,
  switch to using broadcast channels instead, which automatically clean
  up after themselves on drop without needing a linear scan
• Bad news is that we have public poll_recv methods on Signal and after a cursory glance I could not figure out how to refactor broadcast::Receiver to have an internal version of poll_recv as we had in mpsc::Receiver, so appreciate any help here!
• PR is still WIP, but I wanted to start getting feedback

Refs #3550

[carllerche]

The direction looks good. I think you can use watch here as you are doing broadcast::channel(1). There also is a poll bridge here. You will probably want to vendor a bunch of that in a private tokio module for this signal work.

Thanks 👍

[ipetkov]

@Darksonn @carllerche this is now ready for (final) review!

[Darksonn]

There's a merge conflict.

[ipetkov]

Rebased

[ipetkov]

Test failure is for test tokio full --unstable (macos-latest), can't find any logs wonder if the runner just died somehow. Going to restart and see if it passes

[carllerche]

Thanks! Super close. Code looks good, I had one nit inline.

Could you add a valgrind test? Ex. https://github.com/tokio-rs/tokio/blob/master/.github/workflows/ci.yml#L71-L91

[ipetkov]

Added a test, CI is passing now, let me know if anything else is missing!

[carllerche]

LGTM thanks 👍. I'll let @Darksonn do the final review / merge.

[Darksonn]

Seems fine to me.