Fix namespace selector performance issues on large clusters

[jakolehm]

Switches to "search only mode" if user has > 500 namespaces. This seems to help a lot with clusters that have huge number of namespaces (tested with >12k namespaces).

Note: this changes ns selector behaviour a bit. If user selects "All namespaces" it does not mark anymore every namespace as selected, instead it marks "All namespaces" as selected. I had to make this change so that logic works also with "search only mode".

https://user-images.githubusercontent.com/1446224/146182668-183eaf9b-385e-413d-92db-d77219d73413.mov

[Nokel81]

Note: this changes ns selector behaviour a bit. If user selects "All namespaces" it does not mark anymore every namespace as selected, instead it marks "All namespaces" as selected. I had to make this change so that logic works also with "search only mode".

I am slightly concerned about this change as it means that you can no longer deselect a namespace from the "all-namespaces" set.

[jakolehm]

Note: this changes ns selector behaviour a bit. If user selects "All namespaces" it does not mark anymore every namespace as selected, instead it marks "All namespaces" as selected. I had to make this change so that logic works also with "search only mode".

I am slightly concerned about this change as it means that you can no longer deselect a namespace from the "all-namespaces" set.

You still can, it just looks a bit different.

[jakolehm]

@Nokel81 ptal again.

[jim-docker]

I'm seeing issues on linux when connected to a large cluster (i.e. prod's catalog cluster):

https://user-images.githubusercontent.com/40840436/146268910-a1425da6-cbe8-42f6-8f14-f5d435edf2cf.mov

The above video shows trying to select multiple namespace search matches. The Lens UI freezes, eventually the logs show:

[0] error:   ▪ [CLUSTER]: Failed to connect to "Default": RequestError: Error: socket hang up +1ms
[0] [CLUSTER-CONNECT] 3 active sockets
[0] [CLUSTER-CONNECT] 3 active sockets
[0] 
[0] (electron:23882): Gtk-WARNING **: 15:46:54.138: Could not load a pixbuf from icon theme.
[0] This may indicate that pixbuf loaders or the mime database could not be found.
[0] **
[0] Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
[0] /home/jim/git/lensapp/lens/node_modules/electron/dist/electron exited with signal SIGABRT
[0] [nodemon] app crashed - waiting for file changes before starting...

I left Lens running after that and the screen saver eventually kicked in so maybe that precipitated the crash?

5.3.3 on linux is also laggy, has connect issues, and namespace selection also makes the UI laggy or non-responsive, so this PR doesn't necessarily make things worse on linux...

[jim-docker]

This is the app from a make build run (and I installed the Lens spaces extension manually):

https://user-images.githubusercontent.com/40840436/146278345-571de8c0-3efb-435b-8b25-9948179fbec0.mov

When the app started up the selected namespaces was initially default I changed it to All Namespaces, then tried to search for space-001. The results eventually showed up (after the end of the video above). It also froze the UI after I tried to ctrl-click one of them (like the video in my comment above). And then the core dumped:

[CLUSTER-CONNECT] 6 active sockets
[CLUSTER-CONNECT] 6 active sockets
Segmentation fault (core dumped)

Another thing seems odd, that it tried to do a watch on pods using the array of what looks like all of the namespaces. Should that have happened? The selected namespaces went from default to All Namespaces, which should use the equivalent of --all-namespaces not an array of all the namespaces, right?

[jim-docker]

The "Search Namespaces..." text seems to be sticky. After opening the dropdown it doesn't go away upon closing it.

https://user-images.githubusercontent.com/40840436/148097200-6be166f4-2d69-4df2-a8ec-bc6c7408c022.mov

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[Nokel81]

Closing because this PR is very old