Add executable scripts to start certbot and acme server in certbot-ci (#7073)

During review of #6989, we saw that some of our test bash scripts were still used in the Boulder project in particular. It is about `tests/integration/_common.sh` in particular, to expose the `certbot_test` bash function,  that is an appropriate way to execute a local version of certbot in test mode: define a custom server, remove several checks, full log and so on.

This PR is an attempt to assert this goal: exposing a new `certbot_test` executable for test purpose. More generally, this PR is about giving well suited scripts to quickly make manual tests against certbot without launching the full automated pytest suite.

The idea here is to leverage the existing logic in certbot-ci, and expose it as executable scripts. This is done thanks to the `console_scripts` entry of setuptools entrypoint feature, that install scripts in the `PATH`, when `pip install` is invoked, that delegate to specific functions in the installed packages.

Two scripts are defined this way:
* `certbot_test`: it executes certbot in test mode in a very similar way than the original `certbot_test` in `_common.sh`, by delegating to `certbot_integration_tests.utils.certbot_call:main`. By default this execution will target a pebble directory url started locally. The url, and also http-01/tls-alpn-01 challenge ports can be configured using ad-hoc environment variables. All arguments passed to `certbot_test` are transferred to the underlying certbot command.
* `acme_server`: it set up a fully running instance of an ACME server, ready for tests (in particular, all FQDN resolves to localhost in order to target a locally running `certbot_test` command) by delegating to `certbot_integration_tests.utils.acme_server:main`. The choice of the ACME server is given by the first parameter passed to `acme_server`, it can be `pebble`, `boulder-v1` or `boulder-v2`. The command keeps running on foreground, displaying the logs of the ACME server on stdout/stderr. The server is shut down and resources cleaned upon entering CTRL+C.

This two commands can be run also through the underlying python modules, that are executable.

Finally, a typical workflow on certbot side to run manual tests would be:
```
cd certbot
tools/venv.py
source venv/bin/activate
acme_server pebble &
certbot_test certonly --standalone -d test.example.com
```

On boulder side it could be:
```
# Follow certbot dev environment setup instructions, then ...
cd boulder
docker-compose run --use-aliases -e FAKE_DNS=172.17.0.1 --service-ports boulder ./start.py
SERVER=http://localhost:4001/directory certbot_test certonly --standalone -d test.example.com
```

* Configure certbot-ci to expose a certbot_test console script calling certbot in test mode against a local pebble instance

* Add a command to start pebble/boulder

* Use explicit start

* Add execution permission to acme_server

* Add a docstring to certbot_test function

* Change executable name

* Increase sleep to 3600s

* Implement a context manager to handle the acme server

* Add certbot_test workspace in .gitignore

* Add documentation

* Remove one function in context, split logic of certbot_test towards capturing non capturing

* Use an explicit an properly configured ACMEServer as handler.

* Add doc. Put constants.

docs/contributing.rst

@@ -17,6 +17,8 @@ its dependencies, Certbot needs to be run on a UNIX-like OS so if you're using
 Windows, you'll need to set up a (virtual) machine running an OS such as Linux
 and continue with these instructions on that UNIX-like OS.
 
+.. _local copy:
+
 Running a local copy of the client
 ----------------------------------
 
@@ -89,6 +91,17 @@ tests, and be compliant with the :ref:`coding style <coding-style>`.
 Testing
 -------
 
+You can test your code in several ways:
+
+- running the `automated unit`_ tests,
+- running the `automated integration`_ tests
+- running an *ad hoc* `manual integration`_ test
+
+.. _automated unit:
+
+Running automated unit tests
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 When you are working in a file ``foo.py``, there should also be a file ``foo_test.py``
 either in the same directory as ``foo.py`` or in the ``tests`` subdirectory
 (if there isn't, make one). While you are working on your code and tests, run
@@ -114,16 +127,16 @@ of output can make it hard to find specific failures when they happen.
   config if your user has sudo permissions, so it should not be run on a
   production Apache server.
 
-.. _integration:
+.. _automated integration:
 
-Integration testing with the Pebble CA
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Running automated integration tests
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Generally it is sufficient to open a pull request and let Github and Travis run
 integration tests for you. However, you may want to run them locally before submitting
 your pull request. You need Docker and docker-compose installed and working.
 
-The tox environment `integration` will setup Pebble, the Let's Encrypt ACME CA server
+The tox environment `integration` will setup `Pebble`_, the Let's Encrypt ACME CA server
 for integration testing, then launch the Certbot integration tests.
 
 With a user allowed to access your local Docker daemon, run:
@@ -135,6 +148,52 @@ With a user allowed to access your local Docker daemon, run:
 Tests will be run using pytest. A test report and a code coverage report will be
 displayed at the end of the integration tests execution.
 
+.. _Pebble: https://github.com/letsencrypt/pebble
+
+.. _manual integration:
+
+Running manual integration tests
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can also manually execute Certbot against a local instance of the `Pebble`_ ACME server.
+This is useful to verify that the modifications done to the code makes Certbot behave as expected.
+
+To do so you need:
+
+- Docker installed, and a user with access to the Docker client,
+- an available `local copy`_ of Certbot.
+
+The virtual environment set up with `python tools/venv.py` contains two commands
+that can be used once the virtual environment is activated:
+
+.. code-block:: shell
+
+    run_acme_server
+
+- Starts a local instance of Pebble and runs in the foreground printing its logs.
+- Press CTRL+C to stop this instance.
+- This instance is configured to validate challenges against certbot executed locally.
+
+.. code-block:: shell
+
+    certbot_tests [ARGS...]
+
+- Execute certbot with the provided arguments and other arguments useful for testing purposes,
+  such as: verbose output, full tracebacks in case Certbot crashes, *etc.*
+- Execution is preconfigured to interact with the Pebble CA started with ``run_acme_server``.
+- Any arguments can be passed as they would be to Certbot (eg. ``certbot_test certonly -d test.example.com``).
+
+Here is a typical workflow to verify that Certbot successfully issued a certificate
+using an HTTP-01 challenge on a machine with Python 3:
+
+.. code-block:: shell
+
+    python tools/venv3.py
+    source venv3/bin/activate
+    run_acme_server &
+    certbot_test certonly --standalone -d test.example.com
+    # To stop Pebble, launch `fg` to get back the background job, then press CTRL+C
+
 Code components and layout
 ==========================