BIGTOP-3801: Add maven cache volume for docker provisioner

[yoda-mon]

Description of PR

This PR adds an option that adds a docker volume and mounts .m2 during the build.
Adding this option, users could reduce the build time by skipping some download processes.

Detail

./gradlew target-ind -POS=ubuntu-20.04 -Pmvn-cache-volume=true

or

cd bigtop-ci; bash -xe ./build.sh --prefix trunk --os ubuntu-20.04 --target zookeeper-pkg --mvn-cache true

With this option, bigtop create docker volume that named bigtop-mvn-cache-$OS if not exists and mount it on /var/lib/jenkins/.m2 in the provisioner container. If the volume has already existed, bigtop reuse it.

If users set the option false, bigtop try to remove the volume and build without the cache.
If users does not set any option for this, bigtop do nothing for mounting the volume (Same behavior with before).

How was this patch tested?

I checked on Ubuntu 22.04/x86 host machine.

1st build with the cache option.

$ nohup ./gradlew zookeeper-clean zookeeper-pkg-ind -POS=ubuntu-20.04 -Pmvn-cache-volume=true > nohup-true-1.out 2>&1 < /dev/null
...
BUILD SUCCESSFUL in 6m 10s

Check the volume.

$ docker volume ls
DRIVER    VOLUME NAME
local     bigtop-mvn-cache-ubuntu-20.04

$ docker run -it --rm -v bigtop-mvn-cache-ubuntu-20.04:/root/.m2 ubuntu:20.04 ls -l /root/.m2/
total 4
drwxr-xr-x 46 1000 1000 4096 Sep  2 06:40 repository

2nd build with the cache option

$ nohup ./gradlew zookeeper-clean zookeeper-pkg-ind -POS=ubuntu-20.04 -Pmvn-cache-volume=true > nohup-true-2.out 2>&1 < /dev/null
...
BUILD SUCCESSFUL in 1m 40s

Set the option false

$ nohup ./gradlew zookeeper-clean zookeeper-pkg-ind -POS=ubuntu-20.04 -Pmvn-cache-volume=false > nohup-false.out 2>&1 < /dev/null &
...
BUILD SUCCESSFUL in 6m 14s

Check the deletion

$ docker volume ls
DRIVER    VOLUME NAME

Set no option

$ nohup ./gradlew zookeeper-clean zookeeper-pkg-ind -POS=ubuntu-20.04 > nohup-no.out 2>&1 < /dev/null &
...
BUILD SUCCESSFUL in 6m 10s

For code changes:

• Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'BIGTOP-3638. Your PR title ...')?
• Make sure that newly added files do not have any licensing issues. When in doubt refer to https://www.apache.org/licenses/

[iwasakims]

LGTM. It worked as expected on CentOS 7 aarch64 too. Thanks, @yoda-mon.