Add support for use of prebuilt test Daphne container image.

[branlwyd]

This is controlled by a new compile-time DAPHNE_INTEROP_CONTAINER
environment variable (matching the JANUS_INTEROP_CONTAINER variable used
to control building of the Janus interop test containers). See the
updates to README.md for more details.

Also:

• Update Daphne to the latest commit. This is important as it picks up
  Trigger don't-clear-the-agg-job-queue behavior on a new variable. cloudflare/daphne#99 which de-flakes
  Janus/Daphne integration tests again after they were accidentally
  re-flaked by switching to DAP_DEPLOYMENT=prod.
• Add ability to skip building the Daphne container, and do so for our
  CI lints.

[branlwyd]

Notes:

• As part of this I pushed a daphne_test image to our private infra, and tested that it works as a prebuilt target. I'd like to set up CI to use it too, but before I do: the name of the image includes the name of our private Docker repo; should this be stored in a secret? (I think the answer is yes, but I want to poll folks before I add the secret.)

[divergentdave]

Putting the image name in a GHA secret makes sense to me, as attempting to use it outside a workflow under our control would result in an authentication error.

[tgeoghegan]

I'm uncomfortable with us being Daphne's build system, and with the amount of surprising side effects that running cargo test or cargo build is sprouting, like putting images into your local Docker image repository. I don't want to block forward progress but I hope we have a plan to stop building Daphne in this project, and I also think we should consider moving what are plainly expensive and complicated integration tests out of the cargo test path, which I think people generally expect to be pretty cheap and safe to run.

[tgeoghegan]

This is going to break if the layout of the Daphne repository changes, right?

[branlwyd]

Yes, we will have to update these instructions to account for backwards-incompatible changes in Daphne's build system when we bump Daphne versions, similarly to the human-targeted instructions. (note that we fix a version of Daphne under test, so changes to the Daphne repo won't trigger the need to make these changes automatically)

[branlwyd]

I'm uncomfortable with us being Daphne's build system

We aren't Daphne's build system? We just build Daphne.

and with the amount of surprising side effects that running cargo test or cargo build is sprouting, like putting images into your local Docker image repository.

cargo {build,test} also puts binary artifacts into your /target/ directory -- think of it like that.

I don't want to block forward progress but I hope we have a plan to stop building Daphne in this project,

This PR is the plan: it allows you to use a prebuilt Daphne container rather than building the image yourself.

and I also think we should consider moving what are plainly expensive and complicated integration tests out of the cargo test path, which I think people generally expect to be pretty cheap and safe to run.

Disagree: cargo test should run all tests, without the need for folks to look up complicated one-off invocations to run the "special" tests that we decided are too complicated.

We could hide these behind a feature, if we needed to. But TBH, the tests run quite quickly, and with prebuilt support the build-time hit is completely gone. (Even before we had support for prebuilt containers, the build was effectively a one-off since it would be the same every time, unless you cleared your Docker build cache.)

[tgeoghegan]

Fair enough -- I don't have the depth of understanding on this to critique it substantially or more importantly to suggest other strategies, so I think we should move forward, see what if anything is painful and iterate on those points.