Fix 4.2x so that initial requests for large layers are faster

[RyanSutcliffe]

As of 4.21 ArcGIS JavaScript made a change to the way it initially fetches and sets up a new FeatureLayer in the API. There is a request to get the total count of records. This can be extremely slow for large datasets and degrades performance rather than improves it for apps. 

ESRI should fix the API to make the behaviour opt-in, update the docs and release notes to clarify the trade-offs so developers understsand what it is doing and what is best for their use case.

Once ESRI fixes the behavior to make it opt-in, they can reword the release notes like this:

[NealFerguson]

Got burned by this as well moving to 4.24 - Only dealing with 146K point geometries in our case, but some latency issues in the network infrastructure can't immediately be rectified and yielded a 40 sec+ wait for rendering client-side.  Hopefully future releases will take more factors into account rather than "assuming" performance characteristics.  A formal opt-in/opt-out behavior in the API is indeed warranted.

[mgeorge]

Hmm, I'm not sure we would make this opt-in by default, as 3.x also switches to snapshot mode, just at a lower count. Or potentially we could expose different strategies depending on the server. @NealFerguson are you seeing nothing render until 40+ seconds? If you open devtools, are you waiting on a really long count query? What server & version are you using? 

From the testing we did internally, snapshot can significantly improve performance both for AGOL and enterprise (up to so certain point), but if there are some servers & versions in the wild where this is not true, it would be good to add exceptions internally for them.

[mgeorge]

Sorry this popped up & I'm just now realizing this was from a while ago. Our working theory is that this might be specific just to MapServers (trying to get access to a large one internally ATM) & if that's the case, we should be able to modify the querying logic for these services specifically.