feat: PoC

[jamilbk]

Almost a first working version. Needs a few more things wired up but I thought I would get a review on it so far.

Notable things that may differ from how I see the backend is implemented:

• I don't insert a run on page load. Instead I generate a topic which is a random ID that will be used by PubSub for the duration of the test, then form a Phoenix.Token from it we can use to group / authorize all requests for the test
• I don't handle checks as DB records -- instead they're a simple map of booleans
• I use two fields, :num, :rate in the displayed data schema. If we keep this per country in a results table, then displaying data is trivial: just fetch all the rows on page load. When a run completes, we update those counters. I don't think this needs to be wired up to the Liveview for live updates from other people's runs (maybe in the future!)

[jamilbk]

Oh also, I bought a new domain: probe.sh.

I figured it might be wise to run this from another domain just in case.

[jamilbk]

@AndrewDryga I pushed some more updates. It might be good to sync up on a call on a few things I thought about as I was working on this over the weekend.

• Do we need the advanced checks + server responses? I was thinking we could just check that each message type makes it from client -> server and call it a day. Most DPI won't take packet "direction" into account (checking the src and dst fields), and most don't carry much, if any packet state (i.e. sequences) because that eats a lot of RAM. Most will simply drop the handshake initiation.
• If checks are simpler, they can just be a map of booleans on the run record.
• The UI run component just renders the accumulated output of the test along with the current state of the checks map.

As you can see by the quite hacky code quality, I'm biasing towards getting this shipped ASAP. If it's going to be a flop, I'd hate to sink too much time into it.

[AndrewDryga]

Do we need the advanced checks + server responses? I was thinking we could just check that each message type makes it from client -> server and call it a day. Most DPI won't take packet "direction" into account (checking the src and dst fields), and most don't carry much, if any packet state (i.e. sequences) because that eats a lot of RAM. Most will simply drop the handshake initiation.

The reason I'm including that is because they can target headers of response packets, without holding the state of the connection. If you think we can skip that - I'm ok with that.

[AndrewDryga]

I'm merging, we can fix stuff along the way, no need to do a full review here.