Investigate creating prebuilt frontend package

[KlapTrap]

Should we:

1. Pre-build anything at all?
2. Pre-build just the frontend
   Have a mechanism that ensures we deploy a compatible version of the backend when using a prebuilt app.
3. Pre-build frontend and backend
   Needs a build for every environment (windows, linux, macos etc)

[KlapTrap]

Currently we disable aot for cf push due to memory limits in the build stage. Having a pre-build frontend would mean we could always have aot turn on (the angular team recommends this).

[KlapTrap]

PR that added aot: #2594

[nwmac]

I'm not a fan of pre-building the front-end - its still code that is compiled, just as the backend is - it feels it goes against the CF philosophy and buildpacks.

That said, we do have an issue that the front end build with AOT and build optimisation is resource intensive - we try and limit the memory, but the result is the build time often exceeds the 15 minutes allowed by CF.

I think CF should have separate quotes for staging an app versus running it - that way we could allocate more resource for building - but it does not.

We believe Angular 7 (Sept/Oct) will improve build performance - but until that is released we can't gauge what the improvement (if any) is.

Hence, we are considering allowing the front-end (minimally) to be pre-built.

The simplest option (front-end only) is to have an npm target that you run to pre-build the front-end app and which also adds some marker file which the buildpack then uses to know to use the prebuilt UI and skip the build for it.

[nwmac]

We have added support for pre-building the UI - see: https://github.com/cloudfoundry-incubator/stratos/tree/v2-master/deploy/cloud-foundry#pre-building-the-ui