Expand on shareable sessions

[jonatanklosko]

Builds on top of the ideas in #1126.

Overview:

• a user will be able to share a notebook and specify the policy for viewers (can they execute, comment, etc)
• the shared URL should be customizable to allow a readable slug
• support two viewer auth levels: authenticated user (in the given Livebook instance) or anyone (public). Sidenote: authenticated users can access the session either way, but having a read-only URLs for feedback/comments can be useful
• add a clear UI indicator that the given session is shared (both for the editor and the viewer)
• note that users will be able to interact with inputs (in outputs), even without execute permissions (maybe we need a separate policy field for this as well)

Further considerations and ideas:

• we can allow the user to customize which elements of the notebook are visible to viewers (for example to hide code, only show interactive outputs, etc)
• add support for scheduling cell evaluation, as in "run this cell every 30 minutes", to make a notebook self-updating
• how much automatic evaluation do we want? we need to strike a balance between regular notebook and shareable app, since it's a single session
• an option to make a shared session persistent, that is, on Livebook start, a session would automatically be started from a file and evaluated
• automatically restart runtime on crash (?)
• add support for per-user output frames
• show the number of users as a badge on the users icon in the sidebar, to make the information visible without opening the sidebar

Note: these are just some high-level notes at this point.

[josevalim]

We should have two edit modes: edit_text / edit_code (maybe we can call it review/edit) edit_text can add/remove/change markdown cells only. edit_code is everything under edit permissions today.

[jonatanklosko]

After further discussion the new vision is to have two modes:

Share as an app

• sharing creates separate session and immediately evaluates all of the code
• the code builds ("deploys") the app, so any code error is a failure
• that single session is shared with everybody who joins
• the app is interacted with via kino forms and frames (similar to the demos in kino_bumblebee)

Share as a runbook

• a separate session is started whenever someone joins the shared runbook
• conceptually runbook runs top-bottom, similarly to a CI pipeline and possibly pauses in the middle
• there is a single button to start execution
• we need an API for stopping evaluation in expected manner, something like Kino.abort(...); this can be used to programmatically pause if a condition is not satisfied, for example missing input values
• once we get to the end of the notebook, the workflow is concluded

Sidenote: there may still be a value in read-only mode for a plain notebook, but right now our focus is around these two use cases.

[josevalim]

Closing as we broke it apart into smaller issues throughout.