Improve avoid-jitpack workflow

[mchowning]

Trying to improve the avoid-jitpack workflow, particularly the build speeds.

See WPAndroid PR for testing instructions

PR submission checklist:

• I have considered adding unit tests where possible.
• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[mchowning]

The remaining work on this is to figure out a way to include all of the relevant js, css, scss files (any others?) in the task's input so that if any of them change the bundle is regenerated. This worries me because it seems very fragile and when it fails it will not be obvious that the reuse of a previously generated bundle is the problem. 🤔

This is making me think we may be better off publishing the artifacts ourself for devs who are not building Gutenberg from source (i.e., basically create our own Jitpack).

[mchowning]

The remaining work on this is to figure out a way to include all of the relevant js, css, scss files (any others?) in the task's input so that if any of them change the bundle is regenerated. This worries me because it seems very fragile...

Pushed an update that I think addresses that. (6d63c07) Its a bit hacky though, and I'm still concerned about this being fragile. Remaining things I think should be addressed:

• Running the clean gradle task from WPAndroid should regenerate the bundle. This seems really important to me because it makes it relatively trivial to recover if a bundle gets out of date for some reason. Currently a clean does not cause the bundle to regenerate. Addressing this seems critical to me because it makes it significantly easier to recover from unexpected build problems.
• Running a WPAndroid build should not make the gutenberg-mobile submodule "dirty". Currently running a WPAndroid build generates a js bundle modifies ~30 files in the libs/gutenberg-mobile/bundle/ directory. This seems more like a nice-to-have.

[mchowning]

In trying to make clean rerun the task I've realized that for some reason my task is not actually checking the output the way I thought it was. I can delete the bundle and the bundleUpToDateCheck task still shows as UP-TO-DATE and builds an app that crashes when the editor is loaded. 😬

[mchowning]

Just added fc9fbdb, which moves the bundle to the build folder and also has the bundleUpToDateCheck task add an indicator file next to the bundle. I registered that indicator file as an output of the bundleUpToDateCheck task, and it seems to detect that it needs to rerun when that is deleted (still don't understand why it doesn't do the same with the actual bundle file). This means that if you run the clean task, the bundle and the indicator file will both be deleted (because clean deletes the entire build/ folder), and the next build will properly detect that it needs to regenerate the bundle.

[cameronvoell]

Tested via wordpress-mobile/WordPress-Android#11921. Looks good!

[cameronvoell]

Tested via wordpress-mobile/WordPress-Android#11921. Looks good!

Did another round of checks after retargeting and rebase with release branch. Looks good!