cml ci: unshallow repos

[pmrowla]

Docs for cml ci state

Prepares Git repository for CML operations (setting Git user.name & user.email, unshallow clone and undo CI oddities such as origin URL formatting and HTTP remote proxies).

but cml ci does not currently unshallow the clone. It just does fetch --all, which fetches all remote branches, but does not actually modify fetch depth of any of those branches. So in github/gitlab the repo will just have a bunch of shallow branches with depth=1 rather than a single ref/commit with depth=1.

Assuming that unshallowing all clones by default is the intended behavior (which I'm not sure is actually desired, since it will have a significant performance impact in large git repos), what cml ci needs to be doing is something like

# check if the repo is shallow
if [ -f `git rev-parse --git-dir`/shallow ]; then
    git fetch --unshallow
fi
git fetch --all

Note that the check for GIT_DIR/shallow is required since repeated git fetch --unshallow calls will fail if the repo is not actually shallow, which would also cause repeated cml ci calls to fail

(Also, I have not tested the changes in this PR, and I'm not a node/js dev so there's probably a better way of accomplishing this in node)

[pmrowla]

as discussed with @casperdcl, unshallowing should probably not be the default behavior in cml ci, it would be better to have a separate flag for unshallowing, and it should be documented accordingly, this PR can be closed as needed by the cml team

the main issue here is that "use cml ci" is currently being suggested to users as a fix for not being able to run dvc exp run inside CML due to git merge being unsupported in shallow clones (depending on specific fetch depth), but cml ci does not actually resolve the issue right now (and users still need to explicitly set fetch-depth: 0 in the github/gitlab checkout action)

[casperdcl]

Thanks @pmrowla! Just opened #957 simultaneously, woops.