Downgrade blueprintjs version in the web console to one with a vanilla Apache 2.0 license

[vogievetsky]

The new console implemented by #6923 used blueprint.js v3 which has a modified Apache 2.0 license (see clause 10), (see discussion here also).
This has was discovered after the console was already implemented.
A request was raised with Apache legal to see if the modified blueprint Apache license would be acceptable to use in this project.

In the meantime, and so as not to hold up the upcoming 0.14.0 release, this PR downgrades blueprint from v3 to v1.0.1 which was licensed under a vanilla Apache license (as can be seen from the license, readme, and file headers). Blueprint v1.0.1 has a similar look and feel to Blueprint v3.

This change was made with the hope that the modified blueprint license will be approved and the code could in the future be migrated back to the latest blueprint version. If the blueprint license is not approved then it would be recommended to move to a different UI library.

Here is a list of all the major changes that were made to make this work:

• BPv1 uses an icon font instead of SVG icons which requires copying in the assets folder
• The components/filler file is all the shimmed components that in BPv3 were implemented as react components and in BPv1 were pure CSS components
• Using the (React as any).PropTypes = require('prop-types') trick to slap the PropTypes back into react 16 (BPv1 expects react 15)
• Using react-addons-css-transition-group despite deprecation warning
• Changed all dialogs to be inline because the portals did not work in the react 15 / react 16 change
• Changed all dialogs to be created on opening (instead of using the isOpen prop)
• Switched to using AceEditor instead of BP's EditableText which is way better anyway.

[fjy]

👍

[vogievetsky]

Woops, needed to do (React as any).PropTypes = require('prop-types') for the jest tests also

[gianm]

Thanks - this approach looks good to me. I agree that going with a cleanly licensed older version is the right call for now, while we wait for the wheels of license approval on the new one to keep moving. If it ends up moving to a "disallow" then I agree with the suggestion of migrating to a different library at that time.

[clintropolis]

LGTM after CI 👍

Pulled branch and tested locally, UI functional afaict.

[jon-wei]

Are all of these version updates necessary, and can we use fixed package versions instead of "^"?

I think it would be simpler for review and also tracking our dependencies/licenses if we minimize version upgrades

[vogievetsky]

I just upgraded to the latest versions as part of my testing. I figured since I was messing with the package versions anyway I would update things to the latest versions as I was going to be doing comprehensive end-to-end testing anyway. As for using the non-fixed versions that is not an issue as there is a package-lock file included which locks those versions.

[vogievetsky]

also almost all of the 'spurious' things I upgraded are devDependancies in the normal dependency list every change is needed for this PR except @types/hjson which should actually probably be in the dev list also.

[vogievetsky]

Moved @types/hjson to dev list

[vogievetsky]

removed all the package changes other than what is necessary for this PR

[jon-wei]

Cool, thanks