[core] fix(InputGroup): make async control optional

[adidahiya]

Fixes #4375

Checklist

• Includes tests
• Update documentation

Changes proposed in this pull request:

Using the suggestion from #4298 (comment), this change makes "async control" of InputGroup optional, after it was enabled across the board by default in #4266 (released in @blueprintjs/core@3.31.0).

I originally wanted to support all possible <input> use cases out-of-the-box by default with good UX for both synchronous value updates and async ones (see #4262, #4298). This turned out to be too much of a hassle, so I am now opting to make the complex async state handling behavior opt-in using a new prop called asyncControl.

asyncControl={true} should be used in places where applications expect that the state update to a controlled <InputGroup> will be asynchronous, either by explicit design in their state management logic, or through a library like redux-form. I think it makes sense to hide this complexity (and potential source of bugs) behind a flag; see the docs about this:

This is not broadly encouraged (a value returned from onChange should be sent back to the component as a controlled value synchronously)

Reviewers should focus on:

Fix the linked issue, and ensure no regression

[blueprint-bot]

[core] fix(InputGroup): make async control optional

Previews: documentation | landing | table

[blueprint-bot]

run new test only with React 16

Previews: documentation | landing | table

[blueprint-bot]

enable new prop in docs example

Previews: documentation | landing | table

[johnwiseheart]

Looks reasonable, nothing jumps out

[styu]

technically this is a break for folks that were relying on the new async behavior, but now have to add the new prop to turn it on. what do we want to do about that?

[adidahiya]

@styu yeah it is an API break for anyone who has upgraded to the range v3.31.0–3.34.0. I think that's ok since relying on async updates is kind of an edge case for this component, and I'd rather make the default / majority use case work properly.

@tgreen7 @tnrich @ejose19 heads up this API break is likely coming in the next minor release

[adidahiya]

heads up @rynorris as well