Add http2 tracing code

[yzhao1012]

This add 1) grpc client & server; 2) http2_trace_uprobe; 3) additions to http_trace_kprobe to parse http2.

To Do

• [x] Move the images to a .readme_assets folder in this http2_tracing folder.
• [x] Add a "Development" section and move those directions / pre-requisites down there.
• [x] Add the Wireshark directions - do we need to classify port as HTTP2?
• [x] Add a note in the Wireshark section about making sure to launch Wireshark before the client has finished sending messages (increase n to 20?).
• [x] Update final blog post title in both README files.

[yzhao1012]

What do you think of leaving the original simple tracer untouched and copying the kprobe based one into a new directory? I'd kind of prefer to leave the original demo untouched and to avoid creating dependencies.

I think you refer to the dependencies between blog posts. I think that's what we want to call out here, since it makes a point that kprobe tracing plus different parsers works for http & http2 respectively.

Another high-level question is whether we need the kprobe based version if we can make the same point with tcpdump.

I had a vague memory that we touched upon tcpdump at the early phase of drafting. Tcpdump is inferior to kprobe tracers because: 1) itself is not that well-known to microservices users (that's debateable, but general online articles seldom mention it); 2) using it making the parser difficult to integrate. As we have to parse pcap files; 3) it traces network packets, instead of syscalls, further make it odd to Pixie audience, as most is conditioned to read application tracing (this is also debatable, but our intended audience is certainly exposed more application tracing than network tracing in our previous blogs).

[oazizi000]

What do you think of leaving the original simple tracer untouched and copying the kprobe based one into a new directory? I'd kind of prefer to leave the original demo untouched and to avoid creating dependencies.

I think you refer to the dependencies between blog posts. I think that's what we want to call out here, since it makes a point that kprobe tracing plus different parsers works for http & http2 respectively.

At the same time, we don't want to add complexity into the original blog post's demo. I agree with wanting to build off the original, but I think it makes more sense to copy it, and just reference in the blog that it's a "fork" or "copy" of the previous blog-post demo.

[yzhao1012]

Could you update the pixie-demos main repo README to add something like the following:

## http2-tracing

Demo project to accompany the [Debugging with eBPF Part 4: Tracing full body HTTP/2 request/responses](https://blog.px.dev/ebpf-http2-tracing/) blog post. This is a basic example of how to trace HTTP/2 messages using eBPF uprobes. 

(we can update the blog post link once the blog post PR goes live)

I actually missed this part, sorry for that. Thanks for adding that.