Tracking v7 progress toward becoming the default.

## step 1: release

done

## step 2: default for new direct mode repositories

Done when using the command line to init in a crippled filesystem. 

The assistant still creates direct mode repositories though,
and will need to enable annex.thin and adjusted unlocked branch instead.

## step 3: auto-upgrade from direct mode

Direct mode is very buggy and limited, so it's easy for v7 (with adjusted
unlocked branches) to be better than it.

Note that direct mode repos with old git-annex interoperate with adjusted
unlocked repos with new git-annex, so there is no need to wait for v7 to be
widely supported.

One problem with this is that direct mode stores only a single copy
of a file, but v7 unlocked with annex.thin needs two copies if hard links
are not supported. So some users will experience the repo doubling in size.
Limited mostly to windows, also some FAT media. This seems difficult
to avoid though, see discussion in
<http://git-annex.branchable.com/todo/annex.thin_without_hardlinks/>

## step 4: default for all new repositories

Could probably happen fairly soon after switch of direct mode.

This is entirely new repositories that git-annex init is run in for the
first time (no sibling git-annex branches). Limiting to new repos
avoids the problems discussed in step 5.

## step 5: automatic v5 to v7 upgrades

Since v5 repos and v7 repos not using unlocked files are functionally
almost identical, this is unlikely to break much. Unlocking files will of
course change behavior though.

This needs to be deferred until every git-annex likely to be in use
supports v7. A v5 repository may be used by multiple
machines, some not supporting v7 and some that do. If one upgrades to v7
and starts using unlocked files, those files won't be accessible on the old
v5 machines.

> v7 is in debian stable now; oldstable (stretch) has v7 available
> as a backport but not by default, and will remain supported
> until 2022.
> 
> But workflows involving unlocking and re-locking that work on v5 will
> also work on v7 and keep the repo compatible with v5. Only if some
> users commit unlocked files is v5 compatability lost, and even then
> it's easy to re-lock the file to fix compatabilityagain. So the risk
> of a too early upgrade to v7 is not very big.

Note that [[sqlite_database_improvements]] seems to need a v8 mode,
and so is blocked on v5 auto-upgrading.

## step 6: remove support for direct mode

Will simplify a lot of code.

## step 7: remove support for v5

This won't simplify much code, worth doing eventually. Once automatic v5 to
v7 upgrades happen, the remaining v5 specific code is not needed any
longer.