platform: avoid name confliction between platform header and emscripten-libc

[Shikugawa]

Signed-off-by: Shikugawa [email protected]

For an explanation of how to fill out the fields, please see the relevant section
in PULL_REQUESTS.md

Commit Message: Name confliction will occur when we build envoy common library by emscripten because of emscripten-libc. We can avoid this problem with this patch.
Additional Description:
Risk Level: Low
Testing:
Docs Changes:
Release Notes:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]

[jplevyak]

Under what circumstance are we including envoy headers in an emscripten build? This should never happen. This is one of the critical features of Wasm: having a clean API/SDK which does not depend on arbitrary envoy headers.

[Shikugawa]

@jplevyak WASM API/SDK has no problem. So it works fine. But we have situations that we must use envoy headers when we build istio-proxy wasm implementation. If we don't use envoy headers in this situation, we must have a lot of duplicated implementations between istio-proxy and envoy. So I think that we should have an ability to accept portion of envoy headers, shouldn't we?

[jplevyak]

@Shikugawa Sounds like we need some refactoring of the envoy headers. This is also the case for the service protobuf used for gRPC. See #538 This PR allows envoy specific code for envoy wasm plugins. We can refactor envoy so that the bits we need are independent and then include them there.

[Shikugawa]

@jplevyak I think that we still need this. It is caused by platform.h and many headers depend on this. After all, we need to use envoy header (not implementation) to implement without redundancy on istio-proxy.

[lizan]

@jplevyak envoy/common/platform.h is / will be included in almost every header and we should fix it if it doesn't compile in a specific environment. Let's just merge this ?

[jplevyak]

OK, let's merge this. Do we need the code QL ?