Remove a few expired ports:

2020-12-31 audio/ardour: Uses Python 2.7 version of scons, and Python 2.7 which
is EOLed upstream
2020-12-31 audio/mixxx21: Uses Python 2.7 version of scons, and Python 2.7 which
is EOLed upstream
2020-12-31 databases/arangodb32: Uses Python 2.7 which is EOLed upstream
2020-12-31 databases/arangodb33: Uses Python 2.7 which is EOLed upstream
2020-12-31 devel/bzr: Uses Python 2.7 which is EOLed upstream
2020-12-31 devel/chromium-gn: Uses deprecated version of python, use devel/gn
instead
2020-12-31 devel/mongo-cxx-driver: Uses Python 2.7 version of scons, and Python
2.7 which is EOLed upstream

Revert r559792 to unbreak INDEX and bulk -a
It seems a lot of reverse dependencies were missed

With hat:	portmgr

Remove most expired ports that depend on Python 2.7:

Exceptions are:
- mail/mailman, our listservers still use it
- www/chromium, solely because of popular demand,
  upstream is (slowly) working on porting it to Python 3
- ports that have actual patches for Python 3 against
  them (Cinnamon and a few unrelated other ports)
- llvm70 and qt5-webengine because they seem to have a lot
  of dependencies which need further analysis
- sysutils/uefi-edk2-bhyve because bhyve seems to use them
- python2 and python27 themselves

I'm sure there will be complaints, but the nice thing about
a version control system is that we can revert and adjust things.

Sanitize COMMENT per Section 5.6 of the FreeBSD Porter's Handbook (part 1).

Fix more fallout for bundled rocksdb after the LLVM 10 import

In file included from rocksdb/utilities/backupable/backupable_db.cc:16:
rocksdb/util/channel.h:35:33: error: no matching constructor for initialization
of 'std::lock_guard<std::mutex>'
    std::lock_guard<std::mutex> lk(lock_);
                                ^  ~~~~~
/usr/include/c++/v1/__mutex_base:90:14: note: candidate constructor not viable:
1st argument ('const std::mutex') would lose const qualifier
    explicit lock_guard(mutex_type& __m)
_LIBCPP_THREAD_SAFETY_ANNOTATION(acquire_capability(__m))
             ^
/usr/include/c++/v1/__mutex_base:100:5: note: candidate constructor not viable:
no known conversion from 'const std::mutex' to 'const
std::__1::lock_guard<std::__1::mutex>' for 1st argument
    lock_guard(lock_guard const&) _LIBCPP_EQUAL_DELETE;
    ^
/usr/include/c++/v1/__mutex_base:94:5: note: candidate constructor not viable:
requires 2 arguments, but 1 was provided
    lock_guard(mutex_type& __m, adopt_lock_t)
_LIBCPP_THREAD_SAFETY_ANNOTATION(requires_capability(__m))
    ^
1 error generated.

net/ceph* will still not build because Clang crashes but at least
it goes beyond the above error.

Unbreak after r523104

Change cmake default behaviour to outsource.

Ports that build out of source now simply can use "USES=cmake"
instead of "USES=cmake:outsource". Ports that fail to build
out of source now need to specify "USES=cmake:insource".

I tried to only set insource where explictely needed.

PR:		232038
Exp-run by:	antoine

Remove compatibility code for FreeBSD < 11.2 from all ports.

Simplify some ports where DragonFlyBSD no longer needs to be special-cased.
Submitted by:	rene
Reviewed by:	bapt, jbeich
Differential Revision:	https://reviews.freebsd.org/D17724

Add DOCS options to ports that should have one.

Also various fixes related to said option.

PR:		230864
Submitted by:	mat
exp-runs by:	antoine

Adapt ${name}_limits to the new resource limiting mechanics for services

PR:		227219
Submitted by:	0mp
Approved by:	maintainer timeout

databases/arangodb32: Update 3.2.10 -> 3.2.13

Port changes:
* Update of the maintainer's e-mail: galu@packetdam.com -> dev@dudu.ro
* Patch updates

PR:		225698
Submitted by:	Vlad Galu <dev@dudu.ro> (maintainer)

databases/arangodb32: Update to 3.2.10

Additional port change:
* Added LICENSE_FILE

PR:		224563
Submitted by:	Vlad Galu <dev@dudu.ro>
Approved by:	tcberner (mentor)
Differential Revision:	https://reviews.freebsd.org/D13744

update databases/arangodb32 to 3.2.9

PR:		224032
Submitted by:	dev@dudu.ro (maintainer, same as galu@packetdam.com)

fix databases/arangodb32 on FreeBSD 10.x

o Fix build on FreeBSD 10.x by requiring recent LLVM
o Only build on amd64 - many hardcoded directories

PR:		223815
Submitted by:	galu@packetdam.com (maintainer, same as dev@dudu.ro)
Differential Revision:	https://reviews.freebsd.org/D13282

new port: databases/arangodb32

ArangoDB is a production ready highly available Multi-Model NoSQL database

PR:		223240
Submitted by:	dev@dudu.ro
Differential Revision:	https://reviews.freebsd.org/D12793