Reorganize grist docker images and workflows

[jordigh]

My commit messages:

• 12d4d61
  build.sh: add some diagnostic output

As I was testing, I found it useful to see when I was using the ext/
directory or not.

• c5bb86f
  .grist-ee-version: start referencing the intended enterprise version

Since we won't be tracking ext/-directory providers via git (e.g. no
submodules), instead we'll do little version-tracking files like this,
to be used by the recent ext-checkout script.

• 1374d83
  checkout-ext-directory: new helper script

This is just a helper script to get the ext directory of other grist
repos, currently intended for grist-ee.

• 2c941d1
  tsconfig-ext: add /app, /test, and /stubs/app directories

This is so that they get built and tested, as we'll start running
tests on the ext/ directories from now on.

• 7ae5f19
  workflows: build the grist-oss, grist, and grist-ee images

This modifies the workflow to build grist-ee images as well as grist,
which is the same image as grist-ee but merely renamed. The original
image built by these workflows is now called grist-oss.

• 18058f8
  README: Mention the two possible docker images

[paulfitz]

This looks great and organized just as I hoped for. Small comment about a file location.

We need to do a bunch of communication about this change. Here is what I believe is changing, spelling it out just to get it clear:

• The grist-core source code is entirely free and open source.
• The docker image gristlabs/grist is now built from grist-core PLUS some extensions that are source-available, and not free and open source. Inclusion of those extensions is new.
• A docker container running gristlabs/grist will not use those extensions unless an administrator takes an action, such as providing an activation key.
• Switching on extensions would be an action taken by an administrator, and not by general users. If an administrator has not enabled extensions, the experience of the all users should be exactly as it would be if the extensions were not included in the build.

The purpose of this change is so that self-hosters can choose to use services from Grist Labs, or stop using such services, without needing to rework their installation. From a business perspective, we plan to make hybrid hosting easy, where some services such as the formula assistant or end-to-end-encrypted snapshots are simple to offload to Grist Labs to administer if it suits a self-hoster to do so.

We will maintain an image gristlabs/grist-oss which does not contain extensions, for those who prefer that and are not interested in any services Grist Labs may offer, now or in the future.

@jordigh I'd like to see text about this in the README somewhere, and a very short summary and pointer to where to get more information in the workflow yml files.

[paulfitz]

@fflorent @vviers I'd appreciate your eyes on this change, first of all on getting it clearly described, and then on the actual nature of the change.

[jordigh]

@paulfitz I've added a short draft in the README that explains some of the points you outlined above. As we don't yet have a story on how to turn on grist-ee, I am not explaining that yet.

As to being public and vocal that this change happened, I assume that's newsletter material?

Eventually once it all has settled, I think this distinction should go in the help website with both README and docker yaml files linking to the docs website.

[paulfitz]

Thanks @jordigh !

[vviers]

Sorry for being late on reviewing this — thanks for the detailed explanation — this looks OK to us :)