refactor: Parallel Tests

- `disabled_clamav_spamassassin`:
  - Just shuffling the test order around, and removing the restart test at the end which doesn't make sense.

- `postscreen`:
  - Now uses common helper for getting container IP
  - Does not appear to need the `NET_ADMIN` capability?
  - Reduced startup time for the 2nd container + additional context about it's relevance.
  - Test cases are largely the same, but refactored the `nc` alternative that properly waits it's turn. This only needs to run once. Added additional commentary and made into a generic method if needed in other tests.

- `fail2ban`:
  - Use the common container IP helper method.
  - Postscreen isn't affecting this test, it's not required to do the much slower exchange with the mail server when sending a login failure.
  - IP being passed into ENV is no longer necessary.
  - `sleep 5` in the related test cases doesn't seem necessary, can better rely on polling with timeout.
  - `sleep 10` for `setup.sh` also doesn't appear to be necessary.

- `postgrey`:
  - Reduced POSTGREY_DELAY to 3, which shaves a fair amount of wasted time while still verifying the delay works.
  - One of the checks in `main.cf` doesn't seem to need to know about the earlier spamhaus portion of the line to work, removed.
  - Better test case descriptions.
  - Improved log matching via standard method that better documents the expected triplet under test.
  - Removed a redundant whitelist file and test that didn't seem to have any relevance. Added a TODO with additional notes about a concern with these tests.
  - Reduced test time as 8 second timeouts from `-w 8` don't appear to be required, better to poll with grep instead.
  - Replaced `wc -l` commands with a new method to assert expected line count, better enabling assertions on the actual output.

- `undef_spam_subject`:
  - Split to two separate test cases, and initialize each container in their case instead of `setup_file()`, allowing for using the default `teardown()` method (and slight benefit if running in parallel).

- `permit_docker`:
  - Not a parallel test, but I realized that the repeat helper methods don't necessarily play well with `run` as the command (can cause false positive of what was successful).

test/helper/common.bash

@@ -10,6 +10,8 @@ __load_bats_helper
 # -------------------------------------------------------------------
 
 # like _run_in_container_explicit but infers ${1} by using the ENV CONTAINER_NAME
+# WARNING: Careful using this with _until_success_or_timeout methods,
+# which can be misleading in the success of `run`, not the command given to `run`.
 function _run_in_container() {
   run docker exec "${CONTAINER_NAME}" "${@}"
 }
@@ -36,6 +38,12 @@ function check_if_process_is_running() {
   docker exec "${CONTAINER_NAME}" pgrep "${PROGRAM_NAME}"
 }
 
+# @param ${1} target container name [IF UNSET: ${CONTAINER_NAME}]
+function get_container_ip() {
+  local TARGET_CONTAINER_NAME=${1:-${CONTAINER_NAME}}
+  docker inspect --format '{{ .NetworkSettings.IPAddress }}' "${TARGET_CONTAINER_NAME}"
+}
+
 # -------------------------------------------------------------------
 
 # @param ${1} timeout