[#502] experimental test harness using a single container

[d-w-moore]

Automatic launch of specific test scripts in their own container.

[d-w-moore]

Please explain what this PR does?

Are there plans to leverage the consortium test hook and the testing environment?

[....] I wanted to get a start on this issue and get comments in but do not believe this will be merged for the next prc release.

Seems this PR is part of the 2.0.0 milestone after all, so maybe we try to leverage those somewhere in a later release?

[d-w-moore]

Rebasing atop 518.m , and I may leave it that way to save time. After un-drafting, we'll decide if #518 gets its own pull request

[trel]

let's not mention 281 in the first part of the commit lines, we can reference it in the body if helpful/needed.

[d-w-moore]

let's not mention 281 in the first part of the commit lines, we can reference it in the body if helpful/needed.

Yes, will correct that.

[d-w-moore]

Please explain what this PR does?

Are there plans to leverage the consortium test hook and the testing environment?

Basically there are a bunch of tests which demand unique setup or otherwise unique running conditions. This PR is part of a plan to run each of those - automatically is the hope. Inclusion is the idea, preventing regression. And it's easy to set up conditions for such tests within a Dockerfile.

[d-w-moore]

SKIP_IINIT_FOR_PASSWORD documented (currently in 7d75ae9)