Move examples into separate folders.

[Swaagie]

Migrate examples to separate folders.

TODO:

• migrate hello_world
• migrate http_auth_random
• migrate http_headers
• migrate http_body
• migrate http_config
• Build each example as part of CICD (and perhaps run?)
• cargo audit each cargo.toml for examples
• Define documentation on how to build and run each example (per example or general?)

Earlier draft PR discussion

1. Single docker-compose that uses and environment variable to load the matching example. Upside: re-use of docker compose config. Downside: tiny bit of magic to newcomers and newer examples might require more elaborate docker compose config for them to make sense/work.
2. Do we want a separate Cargo.toml files for each example or go with Rust standard approach? It sounds like co-locating (dev-)dependencies was preferred to "avoid" the rustsec vuln from chrono from the main Crate? It would likely require more extensive changes and transition to a workspace.
3. To what extend does raze need to be involved? For devs coming from a mostly Rust background that could be tooling they are unfamiliar with.

fixes #140
fixes #35 by showing how dispatch_http_call works

[PiotrSikora]

1. Single docker-compose that uses and environment variable to load the matching example. Upside: re-use of docker compose config. Downside: tiny bit of magic to newcomers and newer examples might require more elaborate docker compose config for them to make sense/work.

See below (both answers). On one hand examples should be self-contained, on the other hand, Docker and Envoy might add unnecessary compexity as well...

2. Do we want a separate Cargo.toml files for each example or go with Rust standard approach? It sounds like co-locating (dev-)dependencies was preferred to "avoid" the rustsec vuln from chrono from the main Crate? It would likely require more extensive changes and transition to a workspace.

I'd prefer a separate Cargo.toml and src/lib.rs (since it has to be a cdylib for now), so that each example is a self-contained crate that users can copy as a base and evolve into their own plugins.

Working cargo build --examples would be great, but that's a secondary concern.

3. To what extend does raze need to be involved? For devs coming from a mostly Rust background that could be tooling they are unfamiliar with.

Agreed, Bazel integration adds a ton of complexity that isn't strictly necessary. Maybe let's ignore it for now in examples.

FWIW, we can probably land this after v0.2.0 (unless you want to clear cargo-audit warnings in dependent crates?).

[Swaagie]

I think this would be fine to land after 0.2, just so we don't block the WASM reactor change going out. Will allow us to iterate a bit and land on a solid implementation we are all happy with. In addition, would enable you to bring in your uncommitted examples.

edit: having an rustsec ignore on a devDependency of an example is not the worst.

[Swaagie]

I'd prefer a separate Cargo.toml and src/lib.rs (since it has to be a cdylib for now), so that each example is a self-contained crate that users can copy as a base and evolve into their own plugins.

I'll start from this perspective and migrate each example. Having an envoy.yaml with static config is preferred IMHO over something that is generated through some Makefile/script. I agree examples should just be copy paste. This will likely also give clear understanding of docker compose complexity (if any).

[PiotrSikora]

Thanks!