Update web testplan

.github/ISSUE_TEMPLATE/webtestplan.md

@@ -615,7 +615,6 @@ Not available for OSS
 
 ## Web Terminal (aka console)
 
-- [ ] Verify that top nav has a user menu (Main and Logout)
 - [ ] Verify that switching between tabs works with `ctrl+[1...9]` (alt on linux/windows)
 - Update your user role to `require_session_mfa` and:
   - [ ] Verify connecting to a ssh node prompts you to tap your registered WebAuthn key
@@ -794,16 +793,12 @@ Add the following to enable read access to trusted clusters
 - Auth methods
   - Verify that the app supports clusters using different auth settings
     (`auth_service.authentication` in the cluster config):
-    - [ ] `type: local`, `second_factor: "off"`
     - [ ] `type: local`, `second_factor: "otp"`
       - [ ] Test per-session MFA items listed later in the test plan.
     - [ ] `type: local`, `second_factor: "webauthn"`,
       - [ ] Test per-session MFA items listed later in the test plan.
     - [ ] `type: local`, `second_factor: "webauthn"`, log in passwordlessly with hardware key
     - [ ] `type: local`, `second_factor: "webauthn"`, log in passwordlessly with touch ID
-    - [ ] `type: local`, `second_factor: "optional"`, log in without MFA
-    - [ ] `type: local`, `second_factor: "optional"`, log in with OTP
-    - [ ] `type: local`, `second_factor: "optional"`, log in with hardware key
     - [ ] `type: local`, `second_factor: "on"`, log in with OTP
       - [ ] Test per-session MFA items listed later in the test plan.
     - [ ] `type: local`, `second_factor: "on"`, log in with hardware key
@@ -816,7 +811,6 @@ Add the following to enable read access to trusted clusters
         parens. Or set up the connectors on a local enterprise cluster following [the guide from
         our wiki](https://gravitational.slab.com/posts/quick-git-hub-saml-oidc-setup-6dfp292a).
       - [ ] GitHub (asteroid)
-        - [ ] local login on a GitHub-enabled cluster
       - [ ] SAML (platform cluster)
       - [ ] OIDC (e-demo)
   - Verify that all items from this section work on:
@@ -897,12 +891,11 @@ Add the following to enable read access to trusted clusters
   - [ ] Check that those connections are removed after you log out of the root cluster that they
         belong to.
   - [ ] Verify that reopening a db connection from the connections picker remembers last used port.
-- Cluster resources (servers, databases, k8s, apps)
+- Cluster resources
   - [ ] Verify that the app shows the same resources as the Web UI.
   - [ ] Verify that search is working for the resources list.
   - [ ] Verify that pagination is working for the resources list.
-  - [ ] Verify that pagination works in tandem with search, that is verify that search results are
-        paginated too.
+  - [ ] Verify that search results are paginated too.
   - [ ] Verify that you can connect to these resources.
     - Verify that this works on:
       - [ ] macOS
@@ -1149,25 +1142,18 @@ Add the following to enable read access to trusted clusters
   - [ ] Verify that Connect asks for relogin when attempting to connect to an app after cert expires.
     - Be mindful that you need to connect to the app at least once before the cert expires for
       Connect to properly recognize it as a TCP app.
-  - Start the app with debug logs on and tail `tshd.log`. Verify that the UI works correctly in the
-    following scenarios:
-    - All buth the first point assume that you successfully go through the osascript prompt.
-    - Close the osascript prompt.
-      - [ ] The VNet panel shows info about the password prompt being closed.
-    - Start VNet, then stop it.
-      - [ ] The VNet panel doesn't show any errors related to VNet being stopped.
-    - Start VNet, then remove the socket file used for communication with the admin process. It's reported in
-      `tshd.log` as `Created unix socket for admin subcommand socket:<path>`.
-      - [ ] The VNet panel shows an unexpected shutdown of VNet and an in-app notification is shown.
-      - [ ] The admin process cleans up files in `/etc/resolver`.
-    - Start VNet. While its running, kill the admin process.
-      - The easiest way to find the PID of the admin process is to open Activity Monitor, View →
-        All Processes, Hierarchically, search for `tsh` and find tsh running under kernel_task →
-        authtrampoline → bash → tsh. Then just `sudo kill -s KILL <tsh pid>`.
-      - [ ] The VNet panel shows an unexpected shutdown of VNet and an in-app notification is shown.
-      - [ ] The admin process _leaves_ files in `/etc/resolver`. However, it's possible to start
-        VNet again, connect to a TCP app, then shut VNet down and it results in the files being
-        cleaned up.
+  - Start VNet, then stop it.
+    - [ ] Verify that the VNet panel doesn't show any errors related to VNet being stopped.
+  - Start VNet. While its running, kill the admin process.
+    - The easiest way to find the PID of the admin process is to open Activity Monitor, View →
+      All Processes, Hierarchically, search for `tsh` and find tsh running under kernel_task →
+      launchd → tsh, owned by root. Then just `sudo kill -s KILL <tsh pid>`.
+    - [ ] Verify that the admin process _leaves_ files in `/etc/resolver`. However, it's possible to
+      start VNet again, connect to a TCP app, then shut VNet down and it results in the files being
+      cleaned up.
+  - [ ] Start VNet in a clean macOS VM. Verify that on the first VNet start, macOS shows the prompt
+    for enabling the background item for tsh.app. Accept it and verify that you can connect to a TCP
+    app through VNet.
 - Misc
   - [ ] Verify that logs are collected for all processes (main, renderer, shared, tshd) under
         `~/Library/Application\ Support/Teleport\ Connect/logs`.