Make "rust-async" feature optional

[alexlapa]

Fixes #2253

Changes

So I've got pretty much the same issue as described in #2253 - I only use #[frb(sync)], so I want to turn off rust-async and threadpool so there wont be 2*num_cpus threads just hangin there doing nothing. Disabling threadpool works fine, but when I try to disable rust-async I get complation errors:

cannot find function `rust_auto_opaque_encode` in module `flutter_rust_bridge::for_generated`

cannot find type `RustAutoOpaqueInner` in module `flutter_rust_bridge::for_generated`

no method named `dart_fn_handle_output` found for struct `api_bridge_generated::FLUTTER_RUST_BRIDGE_HANDLER` in the current scope

cannot find function `lockable_compute_decode_order` in module `flutter_rust_bridge::for_generated`

unresolved import `flutter_rust_bridge::for_generated::Lockable`

Currently I fix this by having rust-async enbled and declaring a custom FLUTTER_RUST_BRIDGE_HANDLER that has no async executor. Thats fine, but I believe that this should be fixed here.

So this PR tries to make rust-async feature optional and decouple it from dart-opaque.

Procedure and Checklist

In order to quickly iterate and avoid slowing down development pace by making CI pass, only the following simplified steps are needed, and I (fzyzcjy) will handle the rest of CI / moving the tests currently (will have more automation in the future).

• Implement the feature / fix the bug.
• Add tests in frb_example/dart_minimal.
• Make dart_minimal's CI green.

Utility commands

• Run codegen: cargo run --manifest-path /path/to/flutter_rust_bridge/frb_codegen/Cargo.toml -- generate
• Run tests: ./frb_internal test-dart-native --package frb_example/dart_minimal

[alexlapa]

So the reason why CI fails right now is basicaly this:

diff --git a/frb_rust/src/dart_api/dart_api.h b/frb_rust/src/dart_api/dart_api.h
index 1d83c90..7394525 100644
--- a/frb_rust/src/dart_api/dart_api.h
+++ b/frb_rust/src/dart_api/dart_api.h
@@ -837,7 +837,7 @@ typedef Dart_Handle (*Dart_GetVMServiceAssetsArchive)(void);
  * The current version of the Dart_InitializeFlags. Should be incremented every
  * time Dart_InitializeFlags changes in a binary incompatible way.
  */
-#define DART_INITIALIZE_PARAMS_CURRENT_VERSION (0x00000008)
+#define DART_INITIALIZE_PARAMS_CURRENT_VERSION (0x00000009)

...

diff --git a/frb_rust/src/dart_api/dart_version.h b/frb_rust/src/dart_api/dart_version.h
index 5ca0b68..ddfaf3a 100644
--- a/frb_rust/src/dart_api/dart_version.h
+++ b/frb_rust/src/dart_api/dart_version.h
@@ -11,6 +11,6 @@
 // On backwards compatible changes the minor version is increased.
 // The versioning covers the symbols exposed in dart_api_dl.h
 #define DART_API_DL_MAJOR_VERSION 2
-#define DART_API_DL_MINOR_VERSION 5
+#define DART_API_DL_MINOR_VERSION 6

I sure can generate and push updated bindings but this would probably be wrong. I guess that the protocol for this should be something like: regenerated dart-sys, update dart-sys in Cargo.toml, upgrade FRB_MAIN_DART_VERSION and FRB_MAIN_FLUTTER_VERSION in github workflow, upgrade environment.sdk constraint in frb_dart/pubspec.yaml. So it seems to be out of scope fo this PR.

[fzyzcjy]

Great job! Only some small suggestions

[fzyzcjy]

is it possible we do something like

#[cfg(feature = "rust-async")]
pub use tokio::sync::Soemthing;

#[cfg(not(feature = "rust-async"))]
pub use std::sync::Soemthing;

[fzyzcjy]

it would be great to add some tests e.g. following #2681

[fzyzcjy]

No worries about that CI failure caused by dart sdk bump, I will handle it