Cache canary results.

[kyessenov]

Fixes #350

[PiotrSikora]

@ingwonsong @mpwarres @martijneken could you take a look? Thanks!

[ingwonsong]

IIUC, with this PR, we don't make a canary for each VMs. (just doing canary for each plugin).
Would there be any chance to use heterogenous VMs with the same Plugin?
(I don't think this situation is realistic, but just want to check your thoughts.)

[kyessenov]

Can you elaborate on what you mean by a heterogeneous VM? I think the behavior should be the same with or without this PR since we simply cache the result of a computation, assuming plugin_key uniquely identifies an instance.

In the future, this needs to be completely changed so that we only configure once on the main instead of the thread-locals. But given that we have a separate thread local cache already, I think we can delay that.

[ingwonsong]

I meant multiple types of wasm vm engines with "heterogenous" Wasm VM.
BTW, I agree that it would be very rare case, and even if it happen, the difference of VM engine should not affect the result of canary.

LGTM.

[ingwonsong]

After having more chat with @kyessenov, I understood that the canary is cached per WasmHandle, so even though there are multiple types of VM engines, each of them will take canary tests.

[kyessenov]

@PiotrSikora main merge broke CLA :)

[PiotrSikora]

@PiotrSikora main merge broke CLA :)

Argh, I don't know why GitHub UI decided to use my @google.com email instead of the primary one.

Could you remove my commit and push your own merge?

[kyessenov]

@PiotrSikora done and force-pushed.

[PiotrSikora]

Thanks!