Select component should defend against overly-long list of options

[amcclain]

By default, the select component will render all of their options values, which can be a (potentially serious) performance issue as DOM elements are created for every one.

We have an enabledWindowed prop that is usable under certain circumstances - not async, not creatable - and will use a virtual rendering window to avoid this issue. But that prop is false by default, and again cannot be used in all cases.

• We should investigate if the option should always be on by default, when possible.
• If there is some downside to this, could it be auto-activated, when possible, if the number of options exceeds some threshold?
• Has the story around this option changed in any significant way with the newer release of both underlying components (see Update react-select 4.3 → 5.x #3426)? We might well want to revisit that upgrade before changing anything substantial here.
• For async queries, right now the responsibility is on the developer to return a "reasonable" number of results, without any guidance on what that might be. Could we experiment to come up with a recommendation, and then potentially even enforce that as a limit, truncating returned results? There is little utility in showing the user a very long list of matches - if longer than a few dozen, they should almost certainly be encouraged to type more and get more focused results.

The risk with the status quo is that a select might appear to behave very well in development or with some surrounding query that limits its options, but then if a long list of is unexpectedly presented, the rendering delay can be bad enough to freeze up the browser.