Async implementation

[cmcknight-bb]

Hello again, as promised I have made an attempt to implement async over the current uniffi-rs fork version. It seems to be working for our internal poc, so I thought it was a good time to contribute upstream and get some eyes on it. As discussed, rust pointers needed to be marshalled to IntPtr instead of SafeHandle. Performance seems to be ok, I stole the async tests from the kristupas/async-0.24 branch and they pass most of the time, but can be flaky when they do not quite meet the tolerances. Let me know if I need to clarify anything, hope everyone had a great a holiday!

[arg0d]

Nice, it looks like the async performance issues are solved in this PR. I still need a few days to finish reviewing the changes, but this looks good at first glance!

[arg0d]

The async code looks great, it's neat and straight to the point. I left some comments about object synchronization code, and some other minor comments.

I'm more concerned with the performance numbers. It seems like futures can only handle quite small number of calls with scheduling, ~3,000/s. I also tested with uniffi Kotlin, and I'm getting ~5,000/s. Maybe you could also test futures performance on your end? And let me know what kind of performance you are expecting from futures.

If we deem the performance adequate, I think this would be OK to merge after other comments are resolved.

[arg0d]

I left a couple of suggestions how to deal with the flaky tests TestAsyncFallibleFunctions and TestBrokenSleep. Considering that you deem the async performance acceptable, I think it's enough to raise the timing tolerances slightly.

[cmcknight-bb]

I left a couple of suggestions how to deal with the flaky tests TestAsyncFallibleFunctions and TestBrokenSleep. Considering that you deem the async performance acceptable, I think it's enough to raise the timing tolerances slightly.

Committed these changes and flaky tests seem fixed on my end.

I was using the following decorators to disable parallelization for performance testing. I can commit them if you think it would help stability. Just didn't want to conflict with the other open PR.

[Collection(nameof(TestFuturesCollection))]
public class TestFutures
{
...
}

[CollectionDefinition(nameof(TestFuturesCollection), DisableParallelization = true)]
public class TestFuturesCollection { }

[arg0d]

Merging this, thanks for the contribution!