Octue

Summary
Allow services/children to be asked more than one question by a parent.

<!--- START AUTOGENERATED NOTES --->
Contents

Fixes
- [x] Use a new subscriber for each question/answer in `Service` so gRPC connections can be closed immediately after use but `Service` and `Child` instances can be reused
- [x] Ensure `Service` IDs always start with `octue.services` to avoid mismatches between topic/subscription names and `Service` IDs that resulted in broken communication between services
- [x] Make `input_values` parameter of `Child.ask` optional

Testing
- [x] Make `MockSubscriber` raise an error if used after being closed

<!--- SKIP AUTOGENERATED NOTES --->

<!--- SKIP AUTOGENERATED NOTES --->
Contents

Other
- [x] Add developer's guide to deploying services on Google Cloud Run

Summary
Simplify and correct the choice of log formatter on different platforms.

<!--- START AUTOGENERATED NOTES --->
Contents

Enhancements
- [x] Remove `COMPUTE_PROVIDER` and `USE_OCTUE_LOG_HANDLER` from build arguments for Google Cloud Run Dockerfile (just keep as environment variables)

Fixes
- [x] Use correct formatter for analysis logger
- [x] Stop allowing `COMPUTE_PROVIDER` environment variable to override `USE_OCTUE_LOG_HANDLER`

Refactoring
- [x] Move decision on which log formatter to use to new `octue.log_handlers.get_formatter` function

Testing
- [x] Expand and update log handler tests
<!--- END AUTOGENERATED NOTES --->

Reverts octue/octue-sdk-python221

We've had to revert due to limitations in Google Cloud Run:
* Only instances that haven't returned an HTTP status code yet are counted as active
* Acknowledgement of trigger Pub/Sub messages can only be done by returning a status code
* Threads can be launched so the trigger message can be acknowledged to avoid it being sent again, but the instance will then be treated as idle and killed after around 15 minutes
* Together, this means that acknowledgement of trigger Pub/Sub messages can only be done after all processing has completed
* There is also a 600s maximum acknowledgement deadline, after which the message is sent again, resulting in extra containers being spawned and the same computation being carried out multilple times until the first instance of it has finished and acknowledged the trigger message
* This means that long-running processes on Google Cloud Run cause the same processing to happen potentially many times, wasting a lot of compute resource.
* The only solution we can see to this currently (while staying on Google Cloud Run) is to set the acknowledgement deadline to its maximum of 600s and set the message retention deadline to its minimum of 600s so messages for longer-running processes aren't resent
* The long-term solution is to stop using Cloud Run and use something like Knative instead

<!--- SKIP AUTOGENERATED NOTES --->

Summary
Acknowledge Pub/Sub messages received on Google Cloud Run straight away rather than waiting for the analysis to complete first. This avoids triggering the same analysis multiple times (due to Pub/Sub sending the same message multiple times), wasting compute resource, and adding a large amount of noise to the logs.

<!--- START AUTOGENERATED NOTES --->
Contents

Fixes
- [x] Answer questions from Google Cloud Run in a thread

<!--- END AUTOGENERATED NOTES --->

Summary
Allow questions with only an input manifest to be asked (questions with only input values are already allowed).

<!--- SKIP AUTOGENERATED NOTES --->
Contents

Fixes
- [x] Make `input_values` optional in `Service.ask`

<!--- END AUTOGENERATED NOTES --->