docs: in integration tests, use consistent approach to logging and packing

[dwilding]

This PR updates How to write integration tests for a charm and the httpbin-demo charm to be consistent with the Charmcraft 4 profiles and our new machine tutorial:

• How to write integration tests for a charm

  • Use sleep to wait for Juju to process logs, then output the logs to stderr.
  • Change conftest.py to check the CHARM_PATH environment variable instead of packing the charm.
  • Update surrounding docs to clarify that packing should be separate from running integration tests, and to explain how to specify which .charm file to deploy in the tests.
  • Make all tests depend on the charm fixture, for a better failure experience if there's no .charm file available.

  Preview of updated doc

• httpbin-demo charm - Use sleep to wait for Juju to process logs, then output the logs to stderr.

I haven't updated the integration tests in the Kubernetes charm tutorial. We plan to switch the tutorial to use the Charmcraft 4 profile at a later date.

[james-garner-canonical]

Some small suggestions, but looks good to me overall -- and we'll need to update this next cycle when we work on pytest-jubilant anyway.

[james-garner-canonical]

Suggested change

	Your tests will use the context of the current controller in Juju, and by default will create a new model per module, that will be destroyed when the test is finished. The cloud, controller and model name can be specified with the parameters `--cloud`, `--controller` and `--model` parameters.
	Your tests will use the context of the current controller in Juju. By default a new model is created for each test module, that will be destroyed when the test is finished -- this is determined by the scope of the `juju` fixture. The cloud, controller and model name can be specified with the parameters `--cloud`, `--controller` and `--model`.

[tonyandrewmeyer]

Building on James's:

Suggested change

	Your tests will use the context of the current controller in Juju, and by default will create a new model per module, that will be destroyed when the test is finished. The cloud, controller and model name can be specified with the parameters `--cloud`, `--controller` and `--model` parameters.
	Your tests will use the current Juju controller. By default a new model will be created for each test module, which will be destroyed when the test is finished -- this is determined by the scope of the `juju` fixture. The cloud, controller and model name can be specified with the parameters `--cloud`, `--controller` and `--model` parameters.

[dwilding]

Good suggestions, thanks. I adjusted slightly for readability, as I feel the sentence about parameters fits better with the following paragraph. Here's what I've gone with:

Your tests will use the current Juju controller. By default, a new model will be created for each test module. The model will be destroyed when the test is finished. This is determined by the scope of the juju fixture.

Use the --cloud, --controller, and --model parameters to specify the cloud, controller, and model name. If you specify the model name and include the --keep-models parameter, you can reuse a model from a previous test run. For example:

[james-garner-canonical]

Just noticed that 'the model will be destroyed when the test is finished' is a bit inaccurate, since it's not till the module of tests has finished

[dwilding]

Well spotted! I've opened #2154 to fix

[tonyandrewmeyer]

Thanks for doing this. Looks good to me, just a small suggestion building on one from James.

[tonyandrewmeyer]

Building on James's:

Suggested change

	Your tests will use the context of the current controller in Juju, and by default will create a new model per module, that will be destroyed when the test is finished. The cloud, controller and model name can be specified with the parameters `--cloud`, `--controller` and `--model` parameters.
	Your tests will use the current Juju controller. By default a new model will be created for each test module, which will be destroyed when the test is finished -- this is determined by the scope of the `juju` fixture. The cloud, controller and model name can be specified with the parameters `--cloud`, `--controller` and `--model` parameters.