[exupdates][ios] Convert database to swift (#21450)

# Why

This converts a good chunk of the EXUpdates database code to swift.

# How

Convert manually. Unfortunately this couldn't be broken u

[exupdates][ios] Convert database to swift (#21450)

# Why

This converts a good chunk of the EXUpdates database code to swift.

# How

Convert manually. Unfortunately this couldn't be broken up further due
to OpaquePointer return type incompatibility (can't return OpaquePointer
over bridge).

# Test Plan

Run all tests and build app.

# Checklist

<!--
Please check the appropriate items below if they apply to your diff.
This is required for changes to Expo modules.
-->

- [ ] Documentation is up to date to reflect these changes (eg:
https://docs.expo.dev and README.md).
- [ ] Conforms with the [Documentation Writing Style
Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
- [ ] This diff will work correctly for `expo prebuild` & EAS Build (eg:
updated a module plugin).

show more ...

[android][ios] add full infrastructure and implementation for UpdatesBinding (#9694)

# Why

This PR adds the complete infrastructure for allowing the new expo-updates exported JS module to work as

[android][ios] add full infrastructure and implementation for UpdatesBinding (#9694)

# Why

This PR adds the complete infrastructure for allowing the new expo-updates exported JS module to work as a scoped module in the managed workflow codebase and communicate with the `Kernel` classes.

# How

For iOS, I followed the pattern that was used in other scoped modules like Sensors. EXUpdatesBinding is a scoped module that is given access to a pair of kernel services, each of which have access to the AppLoader (and therefore expo-updates state) through the EXKernelAppRecord. All of the properties are just threaded through.

For Android, there were fewer steps to thread through but we weren't keeping a reference to the AppLoader anywhere. I added a simple map in the Kernel for this, which the scoped UpdatesBinding has access to through the KernelProvider.

Finally, since the `Updates.expo.ts` polyfill is no longer needed for the unversioned managed workflow, I removed this code from expo-updates.

# Test Plan

Backport these changes to SDK 38 and add a versioned SDK 38 copy of the expo-updates module, and switch EXKernelAppRecord/Kernel to use the new ExpoUpdatesAppLoader so expo-updates is used.

I launched a test published app created by installing expo-updates and then manually deleting the `build/Updates.expo.*` files from node_modules. All the exported functions from expo-updates worked and assets were resolved to the copies on disk downloaded by expo-updates ��

show more ...

[android][ios] add support for development loads in expo-updates AppLoader (#9599)

# Why

Follow up to #9461 and #9523 . The development client's `AppLoader` classes are used to load manifests for

[android][ios] add support for development loads in expo-updates AppLoader (#9599)

# Why

Follow up to #9461 and #9523 . The development client's `AppLoader` classes are used to load manifests for both development and production bundles, but expo-updates is not intended to be used to load projects in development. We need to bypass expo-updates' caching and database layers for development mode loads.

# How

Unfortunately we cannot reliably determine before loading a manifest whether it is for a development or production mode project. Instead, I've added/expanded upon the ability of the calling class to abort a `LoaderTask` upon its cached/remote manifest callback being fired.

Now, the new ExpoUpdatesAppLoader classes will check for development mode at 3 separate stages -- 1) before starting the load, if the URL is clearly indicative of a project in development, 2) when the cached manifest is returned, and 3) when the remote manifest is loaded. If it determines at any of these three stages that it's trying to load a development mode project, it will abort the `LoaderTask` early and delegate to RN to load the development bundle, similar to how the current, non-expo-updates AppLoader classes in both clients work.

# Test Plan

Manual tests of loading a development mode project on both platforms, after enabling the ExpoUpdatesAppLoader class in Kernel.java/EXKernelAppRecord.m. Also ensured that loading production experiences did not break.

show more ...