Add script for updating proposal tests and daily job for automatic updates

[loganek]

No description provided.

[yamt]

i'm not sure if it's a good idea.

• while it might work for wasi-threads, having build procedure of every proposals here is not scalable.
• it's already easy to run externally hosted test cases w/o this.

[loganek]

I see your concerns, however having all tests in one place simplifies the integration with other runtimes (otherwise all of them would have to build proposals' tests by themselves which pretty much will be a duplicated effort across the community), and I think wasi-threads might actually be one of the complex ones to integrate with right now given there's no wasi-sdk available that supports it yet.

I see a few other options we might consider:

• make sure all proposals implement build.sh file that's self-contained (i.e. already downloads all dependencies like compiler, sdk etc) and builds tests, but that means we most likely repeat the same job in the CI multiple times for each proposal (e.g. if multiple proposals/tests use the same compiler we download it multiple times). There's also a chance that the specific version of toolchain requested by build.sh might not run on the image we use for CI. But maybe those are not such a big problems
• we expect proposals to publish *wasm files along with the source code; that simplifies the process for wasi-testsuite, but also will require from maintainers to build CI action to update test binaries (which maybe is not an unreasonable expectation?)

[loganek]

@yamt I think (?) we both agree we'd like to have amalgamated branch with all proposal's tests. If that's the case, I'd suggest going ahead with this PR so we have something working; we can later update it with different approaches to generate .wasm files. Please let me know if you have strong objections.

[yamt]

@yamt I think (?) we both agree we'd like to have amalgamated branch with all proposal's tests. If that's the case, I'd suggest going ahead with this PR so we have something working; we can later update it with different approaches to generate .wasm files. Please let me know if you have strong objections.

i'm not sure if i agree with having a single "amalgamated branch".
or having a branch to serve binaries at all.
but this patch is ok for me, at least as a temporary solution.