Preparing for addition of headless (token based) serving

[vsoch]

This PR will close #40 and #39. Specifically, additions are the following:

• --headless has been added as an option for start, meaning that the portal is closed off and tokens must be entered to participate. The experiments order is either preset with --experiments and --no-randomize, randomized (default) or filtered to a limited subset (--experiments without --no-randomize),
• expfactory logs can be used inside the container to print out application logs. With --tail they are left open for viewing updates.
• the interactive portal study identifier used to be an incrementing number. To be consistent with the ability to generate a token, the identifier is now an automatically generated 34 character string.
• a development builder container is now available for use for easy testing of (unmerged) features like this one here.

To properly review, we need help! @earcanal, you can use the full functionality of this PR by creating a Dockerfile with the development container.

docker run -v /tmp/data:/data vanessa/expfactory-builder-dev build test-task tower-of-london breath-counting-task

and then build your container from that like before, and please be sure to test both filesystem and relational (sqlite) database types, along with the commands that are outlined in the new docs --> https://github.com/expfactory/expfactory/blob/headless/docs/pages/2-usage.md I've literally been working on this for 9.5 hours straight, so I'm going to take a break while you test. Let's check off the following:

• confirmed working as expected for filesystem and relational databases
• user management commands (generating, refreshing, etc. tokens) work as expected

When things look good I need to:

• tag Github repo with version 3.1
• tag the current builder with version 3.0, and merge and tag this update.
• update expfactory on pypi

Thanks! I need to go for a run now... in the pitch black... lol

[vsoch]

hey @earcanal ! I've added some very basic tests, specifically:

• building the builder
• generating a container from the builder with test task
• starting the container
• checking that curl returns a response
• very basic tests for the client

but circleCI is very limited in being able to execute commands to a container. I think for now we probably can do our best effort in these (somewhat manual) tests, and if you have tested to your satisfaction we can approve and merge and update with a new release. For things like the builder and the robots that I'm working on, my thinking is that those will be moved to their own respective repos so testing is a bit simpler. I don't want to let this PR turn into a larger monster than it already is. Let me know your thoughts!

[earcanal]

Nice! :)