[feature] Implements Envoy WASM extension based on Sentinel Go and proxy-go

[halfrost]

More detail about this feature

Implements Envoy WASM extension based on Sentinel Go and proxy-go (github.com/tetratelabs/proxy-wasm-go-sdk), which will support traffic governance for both HTTP traffic and gRPC services, also it will support configuring rules through Sentinel CRD standard methods

I will work on this feature. If you have any questions or something else want to discuss, welcome to discuss in this issue.

Repo: https://github.com/sentinel-group/sentinel-go-proxy-wasm-extension

[halfrost]

/assign @halfrost

[halfrost]

Regarding my current progress:

I am taking the most basic flow.Rule as an example to run through the whole basic wasm extension logic. I initialize an Entry with simply configure WithTrafficType(base.Inbound). I run sentinel locally and read the wiki, and I found that the interception logic is triggered by the runtime. So what I do now is to initialize sentinel when the Envoy begins to load the wasm plugin. After configuration, I start the go coroutine, and sentinel starts to work (this is my expectation). Then call the entry method in wasm's onXXX api to get the SentinelEntry result.

The problem currently being resolved:

1. Ensure that sentinel's filter is initialized only once in the life cycle
2. Call SentinelEntry and SentinelExit in pairs in onDecode and onEncode, in the correct order.

[halfrost]

Update current progress, I encountered 2 problems and blocked the progress:

1. Due to the limitations of tinygo, cgo cannot be perfectly supported prometheus and etcd. This means that I cannot use etcd and prometheus related functions in wasm plugin. Because both of them depend on xxhash. xxhash requires cgo compilation. So I commented out etcd and prometheus and their associated dependencies. After commenting out, recompiling can indeed pass. But sentinel will have bugs. After debugging, it is found that in the exporter/metric/prometheus/exporter.go:20:2 line, if there is without prometheus client dependency package, the metric is 0, which will cause part of the underlying statistical count of sentinel to be 0, which will directly cause sentinel not to work anymore, and the flow control logic will not be triggered anymore. I have been confusing this part for the two days, but I still haven't gotten over it. Next step, I plan to ask sentinel-golang's developer if there is any workaround if prometheus is removed. I can't think of any other way to bypass this part.
   In the wasm plugin, common statistical counts are easy to implement, but it involves some low-level metrics in prometheus, which are currently limited by tinygo, resulting in compilation errors. I also looked for solutions on Stack Overflow and github, and saw some more complicated wasm plugins. The tinygo version has not yet written functions related to prometheus. Regarding the issue of cgo, I has been submit an issue to the tinygo team. They are currently working on a fix, the issue is here: https://github.com/tinygo-org/tinygo/issues/3044

2. In addition to the cgo problem, there are some problems with reflect function. You may be curious, where is reflect used? In fact, it will be used when reading yaml files. I use map to pass some values ​​to plugin in yaml file, such as resource name, crd path. These are wrapped in a json. When tinygo parses yaml file, it doesn't know what fields are in it, it parses with interface{} type. This will use reflect. I have written the code for reading crd yaml in my current implementation code. But the actual go crashes. The bug is the same as this issue: https://github.com/tinygo-org/tinygo/issues/2660. There is a workaround for this problem, that is, don't pass a map of mutable structures by value. In this way, tinygo will not use interface to run when parsing some parameter. In this way, it will not trigger the reflect bug. But this bug is really common thing. If you pass a json data, it crashes. json is a map of mutable structures.
   For some of the reasons above. I didn't run sentinel wasm plugin completely. Because prometheus is currently involved, I haven't thought of a workaround for the time being. The case I am currently testing is to run the wasm I wrote on envoy. Then curl the corresponding interface on this machine. Trigger the wasm tcp filter, which in turn can test the logic of the tcp filter. I think this feature's main part is to test the logic of sentinel on the wasm plugin.

So currently this feature is still in progress. I will focus on solving the above 2 problems. If you have any good ideas, welcome to discuss with me. Let's make sentinel better. 💪🏻