Fix use of http transport from background isolate

[nielsenko]

After the introduction of realm app caching hot-restart and background isolates no longer works reliably with realm.

Fixes: #1467
Fixes: #1466
Fixes: #1451
Fixes: #1433 (only half fixed by #1445)

[coveralls-official]

Pull Request Test Coverage Report for Build 7612377268

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.2%) to 87.323%

---

Totals
Change from base Build 7555413703:	0.2%
Covered Lines:	3706
Relevant Lines:	4244

---

💛 - Coveralls

[nielsenko]

The issues fixed in this PR was introduced with , but was never released, so I didn't update the CHANGELOG.

Since Apps are now cached and shared we need to be vigilant to always route to the correct isolate in cases such as App.logIn as we potentially need to do the request in another isolate than the one calling, and hence handle async native callbacks in both.

Hence we need to ensure all data is available not only when the callback is scheduled, but also when it actually runs. The current realm C-api expects callback to be executed synchronously, so we need to deep-copy all non-value arguments and handle lifetime explicitly. This involves a bit of simple and dumb native code, such as:

RLM_API void realm_dart_user_completion_callback(realm_userdata_t userdata, realm_user_t* user, const realm_app_error_t* error)
{
    // we need to make a deep copy of error, because the message pointer points to stack memory
    auto error_copy = realm_app_error_copy(error);

    // take an extra ref to the user, so that it doesn't get deleted before we invoke the callback
    std::shared_ptr<realm::SyncUser> user_copy; 
    if (user != nullptr) {
        user_copy = realm_user(*user);
    }

    auto ud = reinterpret_cast<realm_dart_userdata_async_t>(userdata);
    ud->scheduler->invoke([ud, error = std::move(error_copy), user = realm_user(user_copy)]() mutable { 
        (reinterpret_cast<realm_app_user_completion_func_t>(ud->dart_callback))(ud->handle, &user, error.get());
    });
}

Going forward we could:

1. Re-work app caching in core to be better suited for Darts memory model,
2. Create Dart specific C-api with the new binding generator introduced for realm-js, that is geared towards async callbacks,
3. Wait for [vm/ffi] Introduce a NativeCallable.blocking dart-lang/sdk#54554 (comment), which should allow us to get rid of these trampolines, or
4. Just keep adding these trampolines as needed.

BTW: Note that (unrelated to the fix) the Dart native interface has been bumped to 2.2, which is backwards compatible with 2.0 that we used previously.