Implement blocking fan_out_request

[riemass]

Implemented the blocking stuff. There was a small issue I've had with do_receive, since it receives a single message. It behaved weirdly with timespans, so I switched to using time_points. Alternatively, I could've implemented a new receive_cond that awaits n messages, but then I'd have to move from abstract_blocking_actor* to the concrete blocking_actor* implementation. Relates #2009.

[codecov[bot]]

Codecov Report

:x: Patch coverage is 86.32479% with 16 lines in your changes missing coverage. Please review. :white_check_mark: Project coverage is 71.99%. Comparing base (98acd6f) to head (956b008).

Files with missing lines	Patch %	Lines
libcaf_core/caf/blocking_mail.hpp	74.46%	10 Missing and 2 partials :warning:
...bcaf_core/caf/blocking_fan_out_response_handle.hpp	94.20%	4 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2132      +/-   ##
==========================================
+ Coverage   71.89%   71.99%   +0.09%     
==========================================
  Files         632      633       +1     
  Lines       30601    30724     +123     
  Branches     3334     3342       +8     
==========================================
+ Hits        22002    22120     +118     
- Misses       6686     6689       +3     
- Partials     1913     1915       +2     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[riemass]

Aside the review comments I added the dynamically typed receive member.

[Neverlord]

I have a in_flight disposable in the state_. It's a composite disposable created with all the disposables returned from self->request_response_timeout in one case, and clock.schedule_message in the other case. Could returning early and disposing all remaining messages via this disposable be a simpler way to fix this?

The disposable will only cancel the timeouts.

The loop itself is problematic. It will receive those things in order. This means if the first message ID just happens to arrive late (or never and the timeout triggers), you'll wait that entire time, even if another message ID has long arrived and the function could return.

The other issue is that blocking actors have a stash_, where it will keep messages available until they get processed. If we return early here and handle only a single one of the messages, we'll need a way to tell the blocking actor that it has to actively discard the other responses. Otherwise, we'll keep those forever, i.e., have a memory leak.

So this needs to receive messages in a "one of these message IDs please" way and then tell the actor to actively dispose the other responses once they arrive.

Thinking about the timeouts, this will actually use the actor clock, right? In other words, aren't we potentially leaking the timeouts already if they arrive in the mailbox before we call dispose? Response messages will sit in the mailbox forever until they get picked up via their message ID.

Seems like we're opening a whole new can of worms with this. Let's put that on hold for now and discuss it again at another time. Maybe we just leave that out for blocking actors after all if it's too much of a pain to implement.