Fixes#380. Fixes#1794. Fixes#350. Fixes#722.
## Summary
- Pulls all of the onboarding steps out of segue-based storyboards and into code.
- Merges authentication with scanning/manual, reducing steps in auth.
- Removes the "checklist" final screen.
- Supports going 'back' through onboarding steps, e.g. an error after entering a URL.
- Moves permissions from an opt-in "which would you like?" to a required "you must accept/decline this permission" for each permission. See notes below for why.
- Removes the team migration warning from last year.
- Adds landscape & dynamic type support to onboarding. I didn't bother to make the DT do live-updating though.
- Fills in internal & external URL, sets active SSID if possible after location permission.
- Connects to internal URL from discovery instead of base (external) URL.
- Allows onboarding to a server which requests, but does not require, client certificates.
- Allows starting Onboarding skipping the Welcome screen, connects this to the 'add server' row in app configuration when in debug mode.
- Stops calling api/discovery_info for testing connectivity.
- Handles Bonjour updates and removals in the scanning screen.
## Any other notes
Apple is actively blocking 2021.10 (only on iOS) because of an unwritten part of [rule 5.1.1](https://developer.apple.com/app-store/review/guidelines/#5.1.1), saying:
> **Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage**
>
> We noticed your app encourages or directs users to allow the app to access the location. Specifically, your app directs the user to grant permission in the following way(s):
>
> - A message appears before the permission request, and the user can close the message and delay the permission request with the "Continue" button. The user should always proceed to the permission request after the message.
>
> Permission requests give users control of their personal information. It is important to respect their decision about how their data is used.
This is of course referring to our screen which looks like this:
<img width="200" src="https://user-images.githubusercontent.com/74188/136716566-349558d4-d343-4ede-acd6-83b4e66742bc.png">
I love that they're cherry-picking the location part of this when we allow users to do a number of things on this screen. I believe the part of 5.1.1 that they are alluding to here is:
> (iv) Access: Apps must respect the user’s permission settings and not attempt to manipulate, trick, or force people to consent to unnecessary data access. For example, apps that include the ability to post photos to a social network must not also require microphone access before allowing the user to upload photos. Where possible, provide alternative solutions for users who don’t grant consent. For example, if a user declines to share Location, offer the ability to manually enter an address.
They do link to the Human Interface Guidelines' [Accessing User Data](https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/accessing-user-data/) whose section "Displaying Custom Messaging Before the Alert" says:
> **Make it clear that opening the system alert is the only action people can take in your custom-messaging screen.** People can interpret a pre-alert message as a delaying tactic, so it’s critical to let them quickly dismiss the message and view the system alert. If you display a custom screen that precedes a privacy-related permission request, it must offer only one action, which must display the system alert. Use a word like "Continue" to title the action; don’t use "Allow" or other terms that might make people think they’re granting their permission or performing other actions within your custom screen.
I do not believe that we're showing a pre-alert message since we're showing numerous options and allowing the user to pick and choose. Oh well. This new onboarding has improvements in other ways, and maybe is _more_ clear about permissions and what they do, so lemons into lemonade I guess.
37c18f59d0
