Synchronous API for creating instances and Hot-reload fix

[tiholic]

This PR mainly focuses on creating Ably instances in a synchronous manner.
The following changes were made possible as all other operations on each ably instances is an asynchronous operation.

If not async? then, Sync + Lazy = Slazy!!! 😉

1. All platform calls from dart side are made lazy
2. Singleton Ably library instances on Android side (iOS will be caught up)

A peek on new APIs

import 'package:ably_flutter_plugin/ably.dart' as ably;

final clientOptions = ably.ClientOptions.fromKey("<YOUR APP KEY>");
clientOptions.logLevel = ably.LogLevel.verbose; //optional
ably.Rest rest = ably.Ably.Rest(options: clientOptions);

function testRest(){
  ably.RestChannel channel = rest.channels.get('test');
  await channel.publish(name: "Hello", data: "Ably");
}

function testRealtime(){
  ably.Realtime realtime = ably.Ably.Realtime(options: clientOptions);
    realtime.connection.on().listen((ably.ConnectionStateChange stateChange) async {
    print('Realtime connection state changed: ${stateChange.event}');
  });
}

Hot-reload issue fix 🌶️ ♻️ 🎉 🎉

3. registerAbly is now used to dispose off any registered platform instances
4. Android StreamsChannel source is replicated and necessary changes are made to dispose all listeners on hot-reload (Will be removing the streams_channel plugin dependency eventually)

NOTE: Draft PR supporting Android only.

@QuintinWillison @mattheworiordan @paddybyers Please share your feedback on the API. Will make necessary changes and proceed with implementing iOS platform related changes.

[QuintinWillison]

Hi @tiholic ... thanks for your work on this.

Looking pretty good but there are a few things:

1. I see that pubspec.lock has changed but there's no corresponding change to pubspec.yaml... I'm presuming that's because checking in this file was overlooked from a previous PR? Can you keep an eye on this if that is the case as it makes it impossible to look at this PR atomically in respect of the impact it has on the codebase as a whole.
2. Given the nature of plugin development, as I think I may have mentioned a while back, we need to see changes to Java, iOS and the Dart code at the same time - making the PR deliver a feature completely across all runtimes. I'm worried about approving this PR when we have no idea whether this is replicable in Cocoa.
3. In StreamsChannel.java (acknowledging it is somebody else's code) there is inconsistency around the use of final on args to methods. I also had another concern which I commented on directly in that file. This makes me worry a little about the quality of that code. Was it unit tested, for example, where it came from?

I'm going to continue noodling around locally, but I am yet to work out how to actually build the plugin from the command line (i.e. not just run it within the example app). What am I missing? Could we have some instructions somewhere for this, perhaps in the developer notes for now?

Also, one of the things I put in place early on was pedantic. Some of the minor spacing issues and stuff like that I can see in this PR should have been picked up by that. Can I run that from the command line also? It should be running, of course, on every build.

[QuintinWillison]

Thanks for the responses to my review comments, @tiholic.

I think there are still a few improvements before we can merge this. Thanks.

[tiholic]

@QuintinWillison Yeah, this PR is still in draft state. I just getting some inputs on how the final API should look like.
Now that we have enough information to proceed further, I will finish iOS implementation and try to address all the unresolved comments from above.

[tiholic]

@QuintinWillison iOS side caught up, if the runway is clear for landing, we can merge this.

Regarding the pubspec.lock changes, that was probably due to automatic minor version upgrade behavior.
^A.B.C will upgrade packages if minor version releases are available. If we need strict version for dependencies, we can go with package: 'A.B.C' instead of package: '^A.B.C' (ref: https://dart.dev/tools/pub/dependencies)

Updated DeveloperNotes with instructions on static code analysis (includes all build time checks)

[QuintinWillison]

Regarding pubspec.lock changes, I'm happy to leave things as they are for now and thank you for explaining. 😁

There is perhaps a wider discussion to be had here at Ably, across all client libraries, around dependency version management / auto management.

[QuintinWillison]

Happy for you to land this when you are ready, @tiholic. Thanks for all the work you've put in to resolve comments.