add support to wake tamago < 1.23 applets on >= 1.23 os

[abarisani]

This PR adds support for applets built with tamago < 1.23 by making available the previous version of runtime·WakeG.

[mhutchinson]

If this works it'll be excellent. The os/applet split and update policy was always designed with the assumption that we would be able to ensure pin compatibility when upgrading the OS first. It was quite the shock yesterday to realise that assumption might have been invalid.

Trying to retrofit simultaneous atomic upgrade of OS+applet to a remote production fleet was an uncomfortably exciting engineering challenge. If this change can ensure that the OS has support for the old applet at least for a release or two, that engineering challenge becomes much easier. Thanks for this.

[abarisani]

If this works it'll be excellent. The os/applet split and update policy was always designed with the assumption that we would be able to ensure pin compatibility when upgrading the OS first. It was quite the shock yesterday to realise that assumption might have been invalid.

Trying to retrofit simultaneous atomic upgrade of OS+applet to a remote production fleet was an uncomfortably exciting engineering challenge. If this change can ensure that the OS has support for the old applet at least for a release or two, that engineering challenge becomes much easier. Thanks for this.

Unfortunately this assumption breaks in the only points where the OS needs to to introspection on the applet memory using an interface which is outside its control.

There are only two occurrences of this, forcing the applet stack dump and applet parked goroutine wake up.

These two occurrences inevitably make assumptions on the applet runtime.

The applet stack dump is benign, the applet segfaulted anyway and worst case scenario it will stop again as the stack dump is not successful, so I don't think there is an issue here, plus there are protections in place in case symbols are not found (and we could add additional protections on runtime versions to avoid the stack dump if the runtime major version differs, without operational consequences).

The goroutine wake up is the real challenge, and what has been biting us here (but hey, interrupts are hard for good reason!). To defend this choice I can say that the issue has been triggered by a rare major timer re-implementation between Go 1.22 and Go 1.23 which triggered a GOOS=tamago re-implementation of its runtime.WakeG call, raising an incompatibility only on this advanced OS/applet separation.

I now noted that any such occurrence will require the approach of this PR.

However hopefully in the future timers re-implementation will remain a rare occurrence and maybe one day GOOS=tamago will be upstreamed (as GOOS=none) meaning that better and simpler support for the equivalent of WakeG will be possible.