Add bwtester dials and tabs GUI

[mwfarb]

• Added tabs for each app.
• Moved client/server input into color static svg/inputs.
• Moved css and js into separate files.
• Added color arrows showing directionality of tests/content.
• Moved console output into scrollable window.
• Added bwtester tab with dials for each parameter/direction.
• Fixed bwtester command arg formatting issue.
• Added bwtester radio icon lock for each parameter.
• Added bwtester feedback to alter non-locked dials on change.
• Added bwtester feedback when change would exceed max on non-locked dial.
• Added camerapp content over arrow, scaled to fit.
• Added camerapp ability to click and expand image.
• Added button disable when app is running.
• Updated readme with new directions and screenshots.
• Added tooltip note over args input about formatting.

[mwfarb]

@FR4NK-W @chaehni Let me know how this works for you.

[chaehni]

@mwfarb It works really well! Some feedback/ideas for improvement:

• the packets dial doesn't seem to work properly for me. When I lock the packet size and try to turn the packets dial it shows huge numbers and then springs back to its original value.
• When I click the image on the camerapp tab the image does not expand.
• When running the bwtester, in the console the app prints the server-client direction as extra string while the client-server direction is not printed as extra string. Is this intended?
• Can you add some form validation for the client/server addresses to the web interface?

[mwfarb]

@chaehni Thanks for taking a look and finding these issues.

• The packets dial is interesting since it's essentially a potentially large range, so entering large numbers will almost always cause, in your example, bw to far exceed the max 150 Mbps, and so I have it restoring packets to its previous value. I could add a overlay-ed red error message that would fade explaining briefly when chaging a dial exceeds the bounds of the algebra.
• The camerapp link appears to work in Firefox, but not Chrome with this error in the console "Not allowed to navigate top frame to data URL". I'll choose another method that is more cross-platform.
• If you mean the webapp terminal logging printing %!(EXTRA string=-sc=3,1000,30,80000bps, string=). I'm not sure why, but giving golang's exec.Command() more than 5 args results with this logging, but seems to take the "extra" args just fine. I'll see if I can find a way to remove it.
• The html includes field validation, but the Execute button needs to be fixed to validate it.

[mwfarb]

@chaehni I've addressed your comments and fixed a few other issues. Let me know if you have time for another look and review. Thanks!

[mwfarb]

@chaehni Sorry to add another commit to your review. The scionlab environment appears not to have $GOBIN set or run go install on setup, so the scionlab apps may not be compiled for new users. Also, I was mistakenly launching go run for each app run, causing extra compilation time on each run. The majority of this change is to ensure the binaries build on startup, and using the binary only on each app run.

[chaehni]

@mwfarb I had another look and my comments from above are addressed. One idea: Can we limit the range of the dials based on the locked value and the limit of the remaining dial such that it cannot exceed any limits? So if we, for example, lock the packet size the packets dial would be limited to a value that does not exceed the bandwidth limit of 150mbps. Otherwise, it's really hard to set a value for the packets via the dial.

I like that the apps are now installed instead of compiled for every run. I talked to Juan and we want to pre-install the apps in the VMs and run your webapp automatically. So we might only need to check if the apps are installed. (see https://github.com/netsec-ethz/scion-coord/issues/228)

[mwfarb]

The knob library has a non-standard way of displaying the text input box. Have you already tried to click on the number of packets and type in the number you want? If that is the root of setting the number of packets, I should change the display to look more like a standard input box.

[chaehni]

I didn't know you can enter it like this. That makes it a lot more convenient!

[mwfarb]

@chaehni I'd like to update the dial visually in another PR. Ultimately I'd like hash marks for the range of values on the dial, and an input box that is more intuitive to edit. For now, I've added a line of instruction above the dials making it clear that numbers can be typed, edited, clicked, or scrolled to change. Integrating a new dial library now may drag use of other improvements out more weeks.

[chaehni]

@mwfarb Thanks for your work. I think the instructions are good enough for now. We don't need to change the dials in this PR.

[mwfarb]

OK, sounds good. I've removed the unused code and added the error messaging.

[mwfarb]

@chaehni @perrig All commits and comments have been squashed into one. Ready for merging.