Small changes: code reuse, simplify, doc comments, client timeouts

[declark1]

This PR is a batch of several small changes:

• Adds input_masks(), input_detectors(), and output_detectors() helper methods to GuardrailsConfig to reuse code shared by unary and streaming task handlers.
• Moves detection task spawning code from chunk_and_detect() to detect(), consistent with chunk().
• Updates detect() and chunk() code to be easier to follow for new Rustacians
  • Tokio task handles are collected to tasks and separately, try_join_all() is used to await them, collecting results to results
• Added doc and general comments to orchestrator task handlers
• Dropped unneeded tokio::spawn from handle_chunk_task() and handle_detection_task()
• Added default connect and request timeouts for http & grpc clients
  • This is to override actual client defaults which are too high, configurable service-level timeouts will be added in #17
• Added request_id to new requests
• Updated "handling task" (info level) log event to include request_id and exclude inputs text (also addresses #18)
• Fixed broken test_deserialize_config() unit test (tls is currently a required field, although it should be Option)

[gkumbhat]

ideally we would be getting a request id / transaction id from our upstream and it would be good to stick those in logs for tracking purpose and use this as a "default", if not provided. Would you expect any issues with replace this request_id later on? Since you have added it already in downstream functions, it would essentially look like replace request_id with something from request (although it may be in header, so we may need to do some processing)

[declark1]

We haven't instrumented tracing here yet, but I think the trace-id should probably be used for tracking across services? We should probably still have a unique service-level request identifier though, which is what this is for.

If there are additional transaction id(s) provided from upstream services via headers, we can still extract and record them. I haven't seen anything documented on this to know what to expect.

[evaline-ju]

q - can we still tell from this info log vs. the streaming one that this is the "unary" task vs. the "streaming" task?

[declark1]

Currently, no. I was thinking to add detail once we implement streaming and/or additional methods.

I could make this simply "handling unary task" and "handling streaming task", but I assumed there could be additional task types added. I was trying to avoid "handling classification with gen task" and "handling streaming classification with gen task" as these are verbose.

Ideally, these API method names (and associated task handlers) can be renamed/simplified (generate and generate_stream would be nice)

[declark1]

I'll change it to "handling unary task" and "handling streaming task" for now.

[evaline-ju]

LGTM!