internal: remove package-level init with fastlyABIInit()

[dgryski]

We were ignoring the return value anyway and it complicates wizer integration.

[dgryski]

Just need to figure out where to put this for people who want to call it. Maybe at the top-level sdk.go file ?

[joeshaw]

What purpose does the call serve? What're the implications of not calling it?

[dgryski]

The call allows an app to say "I'm using this version of the ABI" and verify that the wasm runtime supports it. However, it is purely advisory and the return value ("Sounds Good" / "I'm sorry I don't support that version") was ignored anyway.

[joeshaw]

What's the right thing to do if we don't support the version? Panic? If so, we could maybe put it into the fsthttp.ServeFunc function since that's going to be the entrypoint for nearly all apps.

[JakeChampion]

What's the right thing to do if we don't support the version? Panic? If so, we could maybe put it into the fsthttp.ServeFunc function since that's going to be the entrypoint for nearly all apps.

I'd possibly also write to stderr so that something appears in fastly log-tail

[fgsch]

Can we just move this into handle.go:Serve(), before we create the ClientRequest?

[dgryski]

There are code entries that could be called before Serve(), for example loading a configuration or something from a kvstore or equivalent. So while it would be seen, it wouldn't necessarily be the first action the SDK would take with the host.

[fgsch]

There are code entries that could be called before Serve(), for example loading a configuration or something from a kvstore or equivalent. So while it would be seen, it wouldn't necessarily be the first action the SDK would take with the host.

Ah, yes, you are right. I still think this should happen automatically (and not something the end user should care about) but I'm not sure how to achieve that outside init or adding the extra check in all the possible entrypoints.