Tolerate nested JSON objects while getting URL

[mikehardy]

Discussion

The firebase storage emulator returns JSON that contains a metadata object that is empty (implying swift [String: Any] type), whereas the cloud API does not (so the current swift [String: String] type works for it)

Thus, attempting to get a download URL against the storage emulator fails since the type checking fails though it does work against cloud APIs.

This may be a bug in the firestore emulator, as it may not be emitting JSON correctly,

However following the theory of "be conservative in what you emit, but liberal in what you accept", it seems slightly better to make a patch here so an empty metadata object is okay. I could be wrong! That would require communication direct between firebase-ios-sdk + firebase-tools crew and could easily be sorted out I'm sure.

In the meantime, here's a patch.

Testing

Here is the JSON from the emulator, logged out from the code, the metadata object is the very last one:

{
 "name":"playground/1666138330416/list/file1.txt",
"bucket":"react-native-firebase-testing.appspot.com",
"generation":"1666138350650",
"metageneration":"1",
"contentType":"text/plain",
"timeCreated":"2022-10-19T00:12:30.650Z",
"updated":"2022-10-19T00:12:30.650Z",
"storageClass":"STANDARD",
"size":"6",
"md5Hash":"LwOwNje/Fik3eT91bw8Vgw==",
"crc32c":"2961208945",
"etag":"1NcPxodhUOK2xSgMzqPjH3WiVUE",
"downloadTokens":"07a6fe7d-0a18-4c01-b1e2-09b718925b70",
"contentEncoding":"identity",
"contentDisposition":"inline",
"metadata":{}
}

With just two type coercions back to String from Any, both of which have fallbacks if the cast is invalid, download URLs come through the new Swift code from the storage emulator just fine.

react-native-firebase test rig exercising this is in progress, but in general it should be reproducible by:

• storage useEmulator
• create any file in storage emulator, using method of choice (putString works fine)
• make reference to that file
• getDownloadUrl on the reference

The problem is also noted in FlutterFire repo, where a test was disabled to workaround this, for now:

firebase/flutterfire#9708
https://github.com/firebase/flutterfire/pull/9708/files#diff-99b8ba26ff8b661cc82057ebd3c6d8121e8e6e95695955d1b5848c3f08e30c91R141-R143

API Changes

• At this time we cannot accept changes that affect the public API. If you'd like to help
  us make Firebase APIs better, please propose your change in a feature request so that we
  can discuss it together.

[paulb777]

Thanks @mikehardy! I'll merge this and add a test and changelog update in another PR