Derived actor from cell

[Kannen]

This is a proposal for a new feature. I do need it in production right now so I implemented it and I propose it here as I think it can be useful.

It allows actor cells to "provide" valid DerivedActorRef. For example this is the test of this new feature included in this pull request:

    #[tokio::test]
    async fn derived_actor_from_cell() {
        let (sx, mut rx) = crate::concurrency::mpsc_bounded(10);
        let (ar, _) = Actor::spawn(None, TestActor, sx).await.unwrap();
        let cell = ar.get_cell();
        let dar = cell.provide_derived::<i32>().unwrap();
        dar.send_message(42).unwrap();
        assert_eq!(rx.recv().await.unwrap(), Msg::I32(42));
        let dar = cell.provide_derived::<i64>().unwrap();
        dar.send_message(33).unwrap();
        assert_eq!(rx.recv().await.unwrap(), Msg::I64(33));
    }
}

For this to work, implementor of actor must implement a new fonction in Actor:

   fn provide_derived_actor_ref<'a>(
            myself: crate::ActorRef<Msg>,
            request: &mut super::RequestDerived<'a>,
        ) {
            request.provide_derived_actor(myself.get_derived::<i32>());
            request.provide_derived_actor(myself.get_derived::<i64>());
        }

By default this method does nothing, so actor_cell.provide_derived() always return None if the referenced actor does not overrides this method.

In my case I need this because I want to put in groups actors that have different message type but that all can provide the same DerivedActorRef type.

The implementation looks quite unsafe, but this is superficial adaptation of the standard library code used to extract backtraces from errors in nightly.

[slawlor]

nit: This comment is very wrong

[slawlor]

uhm what is all this gibberish? This shouldn't be in the repository

[slawlor]

I haven't fully reviewed this PR, but if this is additive, we probably don't need a feature gate. People can choose to use it or not

[slawlor]

ah ok this isn't additive, so the feature is necessary

[slawlor]

nit: usefull in scenario -> useful in scenarios

[slawlor]

nit: Exemple -> Example

[slawlor]

typo? proved_derived_actor_ref

[slawlor]

why can't this be a trait defined on the message type, rather the actor type? An actor who supports derived messages, should support them in aggregate as the messages can be natively converted IMHO.

I.e. if message type A supports derived types B, and C, all actors of message A should support derived message types B and C along with this new from-cell functionality.