chore(deps): bump ngx_wasm_module to prerelease-0.2.0

[flrgh]

This is a backport of #12166. The commit was amended to include a necessary bump to Wasmtime.

---

Changelog 21732b1...388d572

Compare on GitHub

• 388d572 - docs(changelog) prerelease-0.2.0
• 7d3451b - chore(codecov) specify flags in 'flag_management' section
• d59027f - chore(valgrind.supp) consolidate wasmparser::parse suppressions
• 7184a57 - chore(deps) bump OpenSSL to 3.2.0
• 338bcbe - chore(deps) bump zlib to 1.3
• 743c3d3 - chore(deps) cargo update
• 8964b1f - chore(util) minor cleanup/improvements
• f955308 - chore(sdk) separate build and install of .wasm examples
• 8f3fa95 - fix(wasi) do not use instance pool in 'fd_write'
• 4f47e96 - docs(proxy-wasm) document response body buffering
• f813a30 - feat(proxy-wasm) implement response body buffering
• f171e0f - chore(util) always invoke the Proxy-Wasm SDK scripts
• 3d61ca1 - chore(ci) add code coverage for Valgrind jobs
• a278bb7 - tests(*) switch Valgrind tests from 'opt-out' to 'opt-in'
• 9584c03 - fix(proxy-wasm) use filter chain pool in 'ngx_proxy_wasm_maps_set'
• 175f0b8 - chore(util) minor usage fix and style cohesion for scripts
• aefb121 - chore(ci) install Node.js in unit and valgrind jobs
• e757482 - chore(*) clone and test proxy-wasm-assemblyscript-sdk examples
• f2faf97 - chore(util) build Proxy-Wasm SDKs on 'make setup'
• bd1b5b8 - chore(ci) remove 'nginx.sock' before artifact upload on failure
• 65a0b46 - chore(util) use 'git fetch --tags' for updating runtimes
• b51a15f - chore(*) add a .gitattributes file
• 9959389 - fix(*) resolve a possible segfault in the FFI
• 8c45ad1 - fix(*) proper filter modules order in dynamic OpenResty builds
• 33157a8 - feat(proxy-wasm) custom host properties getters/setters
• 81c703e - docs(*) minor fix for a title level
• db88b15 - fix(proxy-wasm) free dispatch calls during resume edge-case
• 5553ae0 - feat(proxy-wasm) strengthen host functions context checks
• ddb3fa8 - docs(*) add AssemblyScript filter example and SDK fork
• ecd7896 - refactor(proxy-wasm) improve pwexec resurrection and instance lifecycle
• 9d304a1 - fix(proxy-wasm) free trapped instances early
• 34c23c6 - fix(proxy-wasm) improve instance recycling robustness
• e3d25c7 - chore(release) install setuptools on macOS
• 689a460 - tests(*) add suites for client/upstream connection aborts
• fa7c59b - misc(tcp) disable a debugging assertion
• d6d04b9 - chore(util) add a patch for tcp_listen in HUP mode
• 67f295b - misc(wrt) add Wasmtime version checks
• ddf8105 - chore(deps) bump Wasmtime to 14.0.3
• de9eb4c - chore(ci) ignore release Dockerfiles changes
• 84fb42b - chore(release) use Python 3.8+ in older distributions
• 9538ad8 - chore(valgrind.supp) add a new suppression for headers-more-nginx-module
• 28e282c - chore(deps) cargo update
• 651728c - chore(deps) bump OpenSSL to 3.1.4
• 3cf7537 - chore(deps) bump Nginx to 1.25.3

---

(cherry picked from commit aba1910)

[flrgh]

Backporting ngx_wasm_module bumps from master is a little bit painful right now because the cadence is different: master is periodically bumped to HEAD, and these bumps don't necessarily get backported to a release branch because they are not pinned to a specific tag. This means that a naive backport of #12166 doesn't include everything we want, as it was only a bump from b51a15f...388d572 whereas release/3.5.x is actually bumped from 21732b1...388d572 by this change.

I did some manual work to update the PR description and commit history, but it was a little tedious. Note to self: it would probably be better if we tweak update-ngx-wasm-module.yml to support custom base branches instead of backporting/cherry-picking from master.

[hishamhm]

@flrgh This only happened because that feature PR included a bump of its own, right? Otherwise it would be possible to sequentially backport previous bumps and get the commit hash updates and history logs in without manual editing.

If that's the case then we could set an operational rule to not bundle bumps in feature PRs, but then the procedure for merging feature PRs that require bumps would become something like "open bump-PR; draft feature-PR including bump; merge bump-PR; drop bump from feature-PR; merge feature-PR". If the bump-PR and feature-PR are reviewed/approved/merged in tandem that wouldn't be too problematic, I think. How does that sound?

[flrgh]

This only happened because that feature PR included a bump of its own, right?

Not exactly. The feature PR was fine because the bump was in a discrete commit.

The reason I would ascribe to this is the policy differences between master and release branches. Because we want master to live on the bleeding edge during the development cycle, it receives periodic bump commits to main/HEAD that the release branch won't.

If C#0 represents the most recent ancestor commit of master and release/3.5.x, and $base represents the commit sha of ngx_wasm_module present in that commit, the history for master will look something like:

C#0 $base
C#1 bump to $base + 1
C#2 bump to $base + 2
C#3 bump to $base + 3

...where, in this case $base + 3 == prerelease-0.2.0, which is desired for release/3.5.x, but we don't necessarily want all of those intermediate commits in the history for release/3.5.x.

In order to get release/3.5.x up to the desired state, we could:

A) cherry-pick commit range C#1..C#3 to a PR branch that targets release/3.5.x and squash at merge time
or
B) create a new (read: not a cherry-pick) commit to bump ngx_wasm_module from $base to prerelease-0.2.0 in a PR which targets release/3.5.x.

In my last comment I was moreso advocating for option B. Now that I've typed all this out, I think either option A or B would work just fine. The mistake I made with this PR was to effectively pick neither 🤦. I just cherry-picked C#3 from master and then twiddled with it by hand until it contained all the proper changes.