[expo-network] Add network state change listeners

[reichhartd]

Why

This PR introduces a approach to handling network state changes across iOS, Android, and Web platforms in the expo-network module. It adds new methods to manage listeners that respond to changes in network connectivity and network state, improving the module's utility in reactive network management scenarios.

How

To implement this feature, I extended the existing expo-network module to include new methods for adding and removing event listeners.

Test Plan

Tested it for Android in the emulator, and for iOS on my physical device (iPhone 11 Pro).

Checklist

• Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md).
• Conforms with the Documentation Writing Style Guide
• This diff will work correctly for npx expo prebuild & EAS Build (eg: updated a module plugin).

[alanjhughes]

Do we need this? addNetworkStateListener will return a subscription. We have the hook to take care of this

[reichhartd]

I implemented it because some other modules implement it (e.g. expo-clipboard). But the question is whether removeSubscription is needed at all, because addListener returns the remove function.

[tsapeta]

As of SDK 51 we no longer need to use additional EventEmitter to send events. The native module object (ExpoNetwork here) already inherits from a new emitter class that is written in C++, see:

• type declaration: https://github.com/expo/expo/blob/main/packages/expo-modules-core/src/ts-declarations/EventEmitter.ts
• new implementation: https://github.com/expo/expo/blob/main/packages/expo-modules-core/common/cpp/EventEmitter.cpp

This also solves a long-standing problem with RN's event emitters which are actually global events – event names from different modules can conflict with each other, thus we used to prefix them with something expo-specific.

[reichhartd]

Thanks for the hint, I have adjusted it. However, it would be good if this change was also reflected in the documentation and in the template (npx create-expo-module my-module).

[tsapeta]

Yeah, we're planning to do this, however:

• We want create-expo-module to be compatible with at least one SDK version older than the latest (actually we're going to version it per-SDK but that's another topic).
• Our docs generation is not yet adjusted to present class inheritance and supported events. We'll also need a new page in the docs that includes all the public APIs exported by the expo package (public and stable APIs from expo-modules-core should be re-exported by expo).

All of those should be solved before SDK 52 though.

[reichhartd]

@alanjhughes @tsapeta Are we ready to merge this? 🙂