Fix test app issues, add tests

[TimSylvester]

In using the iOS app to investigate a bug report, I ran into a bug in the dynamic layout of the dynamically-created view in "Add Second Map."

Aside from resolving that minor issue and adding a test case, I also added a "smoke test" that just clicks on all the items in the menu to make sure they don't crash, but with no validation that they work correctly.

That turned up several problems, such as test cases which can only be run in isolation, and cases which break later cases. For example, "Add Route Line" and "Style Route line with gradient" created sources with the same name, and the style would throw when the second was added.

Currently all the cases are run except for the ones which add 1,000 or 10,000 items, as these seem to take so long that the search for the tappable menu button times out. But they use the same method as the 100 case.

[github-actions]

Bloaty Results (iOS) 🐋

Compared to main

    FILE SIZE        VM SIZE    
 --------------  -------------- 
  [ = ]       0  [ = ]       0    TOTAL

Full report: https://maplibre-native.s3.eu-central-1.amazonaws.com/bloaty-results-ios/pr-2258-compared-to-main.txt

[louwers]

This is really great.

Did the iOS UI tests run on CI? It shows PASSED (Cached).

[TimSylvester]

Did the iOS UI tests run on CI? It shows PASSED (Cached).

I'm not sure what's being cached there. It previously failed repeatedly on CI but worked for me locally on physical and simulated devices. The log seemed to indicate that the target crashed ("Unable to monitor event loop") at 230s. I increased the "size" of the UI test target to extend the timeout from 5 to 15 minutes, and that seems to have resolved it, so I suspect that Bazel was terminating the target before the test framework, and the difference of 70 seconds was the other stuff going on in the build and test setup.

[louwers]

I'll keep an eye on CI. Works great locally.