Implement CLI v2

[hlinnaka]

As described in neondatabase/rfcs#5

This doesn't rely on any Postgres modifications, all the commands have
been implemented in the most naive way possible, with lots of copying data
around. For example, when you initialize a new data directory, we copy
the last snapshot on that timeline to the data directory, instead of doing
it lazily. Doesn't make use of a Page server either.

Take a look at https://github.com/zenithdb/zenith/blob/laptop-cli-v2/cli-v2-story.md for a little walk-through of how to use this. It's close to the examples given in https://github.com/zenithdb/rfcs/blob/6bbca945327a6cb1b4fc09d987235e7c07589f0c/CLI.md.

[kelvich]

Playing with this I can see several areas how CLI v1 and v2 are different:

• One repo / multiple repos

  v1 creates ~/.zenith with absolute paths to repo directory and all stuff is stored there

  v2 initializes repo in a directory where it was initialized. That makes sense while we store everything in files without any daemon on top, but when add daemon into equation (like pageserver) things are more complicated -- should we launch one pageserver for all repos or should we launch separate pageserver for each repo. Single pageserver seems less redundant, but do we need tablespace-like functionality in pageserver now? So let's assume pageserver per repo model for now as a way to unite concepts here.

• Timelines and terminology

  In v2 we have more or less 1-to-1 correspondence between datadir, timeline and branch. Each timeline consist of snapshots and timeline can have parent timeline.

  In v1 there is a 'pg' concept which represents datadir, timeline and branch ('pg create --snapshot=mysnap' is assumed to create new datadir from mysnap and corresponding storage in pageserver ~= timeline). And snapshot are not meant to be grouped into timelines, each snapshot can have it's own parent. From the technical angle that may be actually implemented as a timeline per snapshot. Also if we allow both CoW and non-CoW branches/datadirs implementation should take that into account and do slightly different things.

  In git "branch" command is necessary because file modifications are not going through git itself. But for us only way to create "commit" is to start some postgres and run some queries in it. So we have possibility to avoid that and just have tree of linked snapshots. But branch itself is popular concept on its own, so I'm not sure.

• Storage

  Pageserver vs. local files. We may introduce .zenithconfig in repo during init and state there what kind of storage is used. All other commands can look into this config and use proper implementation. But having two set of commands depending on storage is not good, so let's decide what command do we want.

[hlinnaka]

Superseded by #43