Reland https://github.com/flutter/flutter/pull/136751 with fixes.

Reverts flutter/flutter#136751
Initiated by: vashworth
This change reverts the following previous change:
Original Description:
Reland of https://github.com/flutter/flutter/pull/136562 with fixes.

Reland of https://github.com/flutter/flutter/pull/136562 with fixes.

Reverts flutter/flutter#136562
Initiated by: vashworth
This change reverts the following previous change:
Original Description:
Some of our tests in CI are triggering the `NSLocalNetworkUsageDescription` dialog when they're not supposed to (https://github.com/flutter/flutter/issues/129836) since it's disabled via flags (`--no-publish-port` for flutter/flutter and `--disable-vm-service-publication` for flutter/engine).

Normally, we inject `NSLocalNetworkUsageDescription` (and other bonjour settings) to the Info.plist during the project build for debug and profile mode since by default they will publish the VM Service port over mDNS.

To help diagnose the issue, though, this PR changes it so that we don't inject `NSLocalNetworkUsageDescription` (and other bonjour settings) when port publication is disabled since it shouldn't be needed. Hopefully, this will give us better error messages or cause the app to crash and end the test early (rather than timeout after 30 minutes).

Some of our tests in CI are triggering the `NSLocalNetworkUsageDescription` dialog when they're not supposed to (https://github.com/flutter/flutter/issues/129836) since it's disabled via flags (`--no-publish-port` for flutter/flutter and `--disable-vm-service-publication` for flutter/engine).

Normally, we inject `NSLocalNetworkUsageDescription` (and other bonjour settings) to the Info.plist during the project build for debug and profile mode since by default they will publish the VM Service port over mDNS.

To help diagnose the issue, though, this PR changes it so that we don't inject `NSLocalNetworkUsageDescription` (and other bonjour settings) when port publication is disabled since it shouldn't be needed. Hopefully, this will give us better error messages or cause the app to crash and end the test early (rather than timeout after 30 minutes).

So there appears to be a race situation between the flutter CLI and Xcode. In the CLI, we update the `CONFIGURATION_BUILD_DIR` in the Xcode build settings and then tell Xcode to install, launch, and debug the app. When Xcode installs the app, it should use the `CONFIGURATION_BUILD_DIR` to find the bundle. However, it appears that sometimes Xcode hasn't processed the change to the build settings before the install happens, which causes it to not be able to find the bundle.

Fixes https://github.com/flutter/flutter/issues/135442

--- 

Since it's a timing issue, there's not really a consistent way to test it.

I was able to confirm that it works, though, by using the following steps:
1. Create a flutter project
2. Open the project in Xcode
3. `flutter clean`
4. `flutter run --profile -v`

If I saw a print line `stderr: CONFIGURATION_BUILD_DIR: build/Debug-iphoneos`, that means it first found the old and incorrect `CONFIGURATION_BUILD_DIR` before updating to the the new, so I was able to confirm that it would wait until it updated.

When retrying to connect to the device during app launch, don't uninstall the app first.

Latest test flake for https://github.com/flutter/flutter/issues/120808:
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8770202475999850785/+/u/run_hot_mode_dev_cycle_ios__benchmark/test_stdout

Shows that it uninstalled and then tried debugging and failed, which would make sense since the app wasn't installed anymore.
```
[2023-09-11 18:02:24.555646] [STDOUT] stdout: [   +6 ms] Lost connection to device. Trying to connect again...
[2023-09-11 18:02:24.556949] [STDOUT] stdout: [   +1 ms] executing: /opt/s/w/ir/x/w/recipe_cleanup/tmp53fs1szo/flutter sdk/bin/cache/artifacts/libimobiledevice/idevicesyslog -u 00008030-00144DA10185402E
[2023-09-11 18:02:24.557323] [STDOUT] stdout: [        ] executing: script -t 0 /dev/null /opt/s/w/ir/x/w/recipe_cleanup/tmp53fs1szo/flutter sdk/bin/cache/artifacts/ios-deploy/ios-deploy --id 00008030-00144DA10185402E --bundle build/ios/iphoneos/Flutter Gallery.app --app_deltas build/ios/app-delta --uninstall --noinstall --debug --no-wifi --args --enable-dart-profiling --disable-vm-service-publication --enable-checked-mode --verify-entry-points
[2023-09-11 18:02:24.578010] [STDOUT] stdout: [  +20 ms] [....] Waiting for iOS device to be connected
[2023-09-11 18:02:24.712631] [STDOUT] stdout: [ +134 ms] [....] Using 00008030-00144DA10185402E (N104AP, iPhone 11, iphoneos, arm64e, 16.2, 20C65) a.k.a. 'iPhone 11'.
[2023-09-11 18:02:24.712725] [STDOUT] stdout: [        ] ------ Uninstall phase ------
[2023-09-11 18:02:24.818293] [STDOUT] stdout: [ +105 ms] [ OK ] Uninstalled package with bundle id io.flutter.examples.gallery
[2023-09-11 18:02:24.906833] [STDOUT] stdout: [  +88 ms] ------ Debug phase ------
[2023-09-11 18:02:24.906924] [STDOUT] stdout: [        ] Starting debug of 00008030-00144DA10185402E (N104AP, iPhone 11, iphoneos, arm64e, 16.2, 20C65) a.k.a. 'iPhone 11' connected through USB...
[2023-09-11 18:02:25.285252] [STDOUT] stdout: [ +378 ms] [  0%] Looking up developer disk image
[2023-09-11 18:02:25.529937] [STDOUT] stdout: [ +244 ms] [ 90%] Mounting developer disk image
[2023-09-11 18:02:25.545261] [STDOUT] stdout: [  +15 ms] [ 95%] Developer disk image already mounted
[2023-09-11 18:02:25.587923] [STDOUT] stdout: [  +42 ms] Detected path to iOS debug symbols: "Symbol Path: /Users/swarming/Library/Developer/Xcode/iOS DeviceSupport/16.2 (20C65) arm64e/Symbols"
[2023-09-11 18:02:25.857177] [STDOUT] stdout: [ +269 ms] Script started, output file is /dev/null
[2023-09-11 18:02:25.857259] [STDOUT] stdout: [        ] Script done, output file is /dev/null
[2023-09-11 18:02:25.857511] [STDOUT] stdout: [        ] ios-deploy exited with code 0
[2023-09-11 18:02:25.858066] [STDOUT] stderr: [        ] Could not run build/ios/iphoneos/Flutter Gallery.app on 00008030-00144DA10185402E.
[2023-09-11 18:02:25.858130] [STDOUT] stderr: [        ] Try launching Xcode and selecting "Product > Run" to fix the problem:
[2023-09-11 18:02:25.858214] [STDOUT] stderr: [        ]   open ios/Runner.xcworkspace
[2023-09-11 18:02:25.858537] [STDOUT] stdout: [        ] Installing and launching... (completed in 52.4s)
[2023-09-11 18:02:25.858956] [STDOUT] stderr: [        ] Error launching application on iPhone 11.
```

Xcode uses the CONFIGURATION_BUILD_DIR build setting to determine the location of the bundle to build and install. When launching an app via Xcode with the Xcode debug workflow (for iOS 17 physical devices), temporarily set the CONFIGURATION_BUILD_DIR to the location of the bundle so Xcode can find it.

Also, added a Xcode Debug version of the `microbenchmarks_ios` integration test since it uses `flutter run --profile` without using `--use-application-binary`.

Fixes https://github.com/flutter/flutter/issues/134186.

Sometimes `ios-deploy` loses connection to the device after installing, starting debugserver, and launching. This is shown with an error message like:
```
Process 579 exited with status = -1 (0xffffffff) lost connection
```
This happens frequently in our CI system: https://github.com/flutter/flutter/issues/120808

Usually in CI, on retry it'll work and pass - so this is an attempt to retry without failing the test first. It's not guaranteed to fix since we're unable to recreate this error locally.

Fixes a couple of issues introduced in new iOS 17 physical device tooling: https://github.com/flutter/flutter/pull/131865.

1) Duplicate messages were being filtered out too aggressively. 

For example, if on the counter app, you printed "Increment!" on button click, it would only print once no matter how many times you clicked.

Sometimes more than one log source is used at a time and the original intention was to filter duplicates between two log sources, so it wouldn't print the same message from both logs. However, it would also filter when the same message was added more than once via the same log.

The new solution distinguishes a "primary" and a "fallback" log source and prefers to use the primary source unless it's not working, in which it'll use the fallback. If the fallback is faster than the primary, the primary will exclude the logs received by the fallback in a 1-to-1 fashion to prevent too-aggressive filtering. Once a flutter-message has been received by the primary source, fallback messages will be ignored.

Note: iOS < 17 did not regress.

2) There was a race condition between the shutdown hooks and exiting XcodeDebug that was causing a crash when deleting a file that doesn't exist. This only affects CI  - for the new integration tests and when testing with iOS 17 physical devices.

This PR includes the following changes. These changes only apply to iOS 17 physical devices.

| Command | Change Description  | Changes to User Experience |
| ------------- | ------------- | ------------- |
| `flutter run --release` | Uses `devicectl` to install and launch application in release mode.  | No change.  |
| `flutter run`  | Uses Xcode via automation scripting to run application in debug and profile mode. | Xcode will be opened in the background. Errors/crashes may be caught in Xcode and therefore may not show in terminal. |
| `flutter run --use-application-binary=xxxx` | Creates temporary empty Xcode project and use Xcode to run via automation scripting in debug and profile. | Xcode will be opened in the background. Errors/crashes may be caught in Xcode and therefore may not show in terminal.  |
| `flutter install` | Uses `devicectl` to check installed apps, install app, uninstall app.  | No change.  |
| `flutter screenshot` | Will return error.  | Will return error.  |

Other changes include:
* Using `devicectl` to get information about the device
* Using `idevicesyslog` and Dart VM logging for device logs

Note:
Xcode automation scripting (used in `flutter run` for debug and profile) does not work in a headless (without a UI) interface. No known workaround.

Fixes https://github.com/flutter/flutter/issues/128827, https://github.com/flutter/flutter/issues/128531.

This PR fixes issue of duplicate entries from `xcdevice list` cause devices to not show in `flutter devices`, `flutter run`, etc.

When a duplicate entry is found, use the entry without errors as the authority. If both have errors, use the one with the higher SDK as the authority.

Fixes https://github.com/flutter/flutter/issues/128719.

Workaround solution for: https://github.com/flutter/flutter/issues/121231
See https://github.com/flutter/flutter/issues/120808#issuecomment-1551826299 Error Case 2 for more information.

Sometimes the `ios-deploy` process does not return the logs from the application. We've been unable to figure out why. This is a solution to workaround that by using `idevicesyslog` alongside `ios-deploy` as a backup in getting the log for the Dart VM url. As explained in https://github.com/flutter/flutter/issues/120808#issuecomment-1551826299, when error case 2 happens, the `idevicesyslog` does successfully find the Dart VM.

Also, in the comments of the code it mentions `syslog` is not written on iOS 13+, this was added in response to this issue: https://github.com/flutter/flutter/issues/41133.

However, `idevicesyslog` does in fact work (at least for iOS 16), we use it to collect device logs for our CI tests already: https://github.com/flutter/flutter/blob/1dc26f80f04c1c1091a83c5fead9b3aa83483292/dev/devicelab/lib/framework/devices.dart#L998-L1006

Show warning when attempting to flutter run on an ios device with developer mode turned off (#125710)

This PR adds a warning when a user attempt to `flutter run -d <device id>` on a device without developer mode enabled.
<img width="738" alt="Screenshot 2023-05-09 at 3 53 18 AM" src="https://github.com/flutter/flutter/assets/36148254/6f473a6a-5a0d-438b-9e6f-06d09eb1f3a9">

Also handles multiple partial matches.
<img width="788" alt="Screenshot 2023-05-09 at 3 52 24 AM" src="https://github.com/flutter/flutter/assets/36148254/60c82b3c-d501-4a01-95ad-d6309fe39576">

Fixes https://github.com/flutter/flutter/issues/111988

When tests run in our CI using `flutter drive`, if there is a failure it will loop and try again.

https://github.com/flutter/flutter/blob/434b81f1a58b8528299a63ae7c3ded2aa519e3c9/packages/flutter_tools/lib/src/drive/drive_service.dart#L177-L186

However, it's using the same `device` instance for each iteration. So what was happening was when it would fail to launch, it would tell its listeners that it was cancelled.
https://github.com/flutter/flutter/blob/434b81f1a58b8528299a63ae7c3ded2aa519e3c9/packages/flutter_tools/lib/src/ios/ios_deploy.dart#L486-L489 

Then when the next iteration started, the `vmServiceDiscovery` would immediately return with null because the `deviceLogReader` would be cached from the previous iteration and would already be cancelled. Therefore, bypassing and cancelling the timer.

https://github.com/flutter/flutter/blob/434b81f1a58b8528299a63ae7c3ded2aa519e3c9/packages/flutter_tools/lib/src/ios/devices.dart#L585-L591

https://github.com/flutter/flutter/blob/434b81f1a58b8528299a63ae7c3ded2aa519e3c9/packages/flutter_tools/lib/src/ios/devices.dart#L627

In addition, it seems like sometimes the stop would fail and therefore the the drain would never get the signal that it was done and therefore would hang forever. There was no indication that the stop had failed though because the logs were going to the stream that had no listeners since `deviceLogReader` was already cancelled.
https://github.com/flutter/flutter/blob/434b81f1a58b8528299a63ae7c3ded2aa519e3c9/packages/flutter_tools/lib/src/ios/ios_deploy.dart#L563-L576

Fixes https://github.com/flutter/flutter/issues/127141

Check what is available in the device's iOS DeviceSupport folder to check if symbols were properly fetched. Also, add some logging to track what status the debugger is in.

Debugging for https://github.com/flutter/flutter/issues/121231.

fixes https://github.com/flutter/flutter/issues/120405

Rename variables, update comments, etc from `network` to `wireless` to keep it more uniform.

Also, move non-overriden messages related to device selection into the file they're used.

Part 7 in breakdown of https://github.com/flutter/flutter/pull/121262.

Better support for wireless devices in IDEs

Update device selection to wait for wireless devices to load

Separate attached and wireless devices

This reverts commit 275ab9c6.

Revert "Reland "Remove references to Observatory (#118577)""

This reverts commit 298d8c76.

* Fix typos

* lowercase animated & opacity

* Undo typo fix

---------
Co-authored-by: Michael Goderbauer <goderbauer@google.com>

This reverts commit 2df140f4.

Observatory is being deprecated for Dart 3.0 so it should no longer be
referenced in tooling messaging / flags.

See https://github.com/dart-lang/sdk/issues/50233

* Reland "Support iOS wireless debugging (#118104)"

This reverts commit cbf2e168.

* Remove device loading status

This reverts commit 5cd2d4c6.

* setup wireless debugging to use device IP

* fix tests

* fix unused var and missing annotation

* remove unneeded try catch

* remove commented out line, change null to package id

* better way to get package id

* update mDNS lookup to continously check for server, add messaging if takes too long to find observatory url, update flutter drive to enable publish-port if using network device

* Refactor mDNS Discovery to poll for observatories and better handle multiple instances of the same app. Update drive command to make publish-port more stable. Update attach for iOS to only use Protocol Discovery if applicable, run mDNS and Protocol Discovery simultaneously, handle --debug-port/--debug-url/--device-vmservice-port, continously poll for obseravtories with mDNS, include port in error message when mutliple available

* add and update comments, use logger spinner intead of timer in flutter attach, other small improvements

* add newline to message so next log won't be on same line

* fix install/waiting for permission status progress so it doens't double print the time it took.

* only print backtrace if observatory times out on a physical usb connected device

* fix test

* Update related references from Observatory to Dart VM Service

* fix test

* add debugging options to simulator, test more debugging flags, add tests for other launch arguements

* refactor iOS launch arguments to use one function for both simulator and physical devices

* treat dart flags differently between physical and simulator

* Simplify some flags between devices.

Change --disable-service-auth-codes to not always be included for physical devices, only if disableServiceAuthCodes is true.
Change --disable-observatory-publication to be used for simulator devices too.
Change --enable-checked-mode & --verify-entry-points to be used if debuggingEnabled is true regardless of device type.
Chnage --trace-startup to be used for simulator devices too.

* fix ios release mode with buildable app startApp test

* determine observatory-port from deviceVmServicePort and hostVmServicePort

* add comments and remove hasObservatoryPort