Do we need a streaming equivalent (sugar) for .run_in_actor()?

[goodboy]

So in other words something like ActorNursery.stream_from_actor() which can be used to explicitly call a streaming function (with checks for types built-in) which would avoid the future-y feeling way you'd do it right now with the returned portal.

An example in our test set here looks like this:

async with tractor.open_nursery() as n:

    stream = await(await n.run_in_actor(
        'streamer',
        stream_data,
        seed=11,
    )).result()

Which we could maybe switch to this?

async with tractor.open_nursery() as n:

        stream = await n.stream_from_actor(
            stream_data,
            seed=11,
        )

This does add another method to the API but it is also more explicit and allows for type checking the remote routine at spawn time. Some other notes:

• it's the same number of awaits as the .run_in_actor() usage which
• doing an async for portal.result(): is kind of confusing and unintuitive since in the streaming case the portal returns effectively an AsyncIterator "proxy" of sorts to allow client code to consume values from IPC - in the Portal.run() case (when using .start_actor()) it seems less strange since you're more explicitly expecting back the value you'd get if you called the streaming function locally.
• we might want to think about how cross-actor context manager APIs might look want to look for "one-off" calls as well since this seems like a useful api addition
• maybe we should scrap all these methods and go to a trio nursery style .start() and .start_soon()? Currently we're always using a .start() style where the parent waits for the child to come up before unblocking - Consideration for ".start_soon()" on portals? #155

Opinions very welcome 🤔

[goodboy]

#287 and #290 are related to this and would likely deprecate and remove this.