chore: import upstream snapshot with attribution

docs/guides/events/request_input/index.md

@@ -0,0 +1,53 @@
+# RequestInput
+
+The `RequestInput` class represents a structured request for input from the user, typically used to trigger an interrupt in a workflow (Human-in-the-loop).
+
+## Introduction
+
+In ADK, workflows can be configured to pause and wait for user intervention. The `RequestInput` event is the data structure that represents this interrupt request. It is typically yielded by a workflow node and translated into an `Event` with a special function call (`adk_request_input`) that the client application handles.
+
+Key classes depending on `RequestInput` include `Workflow` (which pauses execution when encountering this event) and various HITL helper utilities (like `create_request_input_event` and `create_request_input_response`) that wrap it. It solves the developer problem of pausing a workflow and gathering structured feedback from a user before resuming.
+
+## Get started
+
+To request input from a user within a workflow, you yield a `RequestInput` object from a node function.
+
+Here is a basic example of a node that requests user details:
+
+```python
+from typing import Any, AsyncGenerator
+from google.adk import Context
+from google.adk.events.request_input import RequestInput
+from pydantic import BaseModel
+
+class UserDetails(BaseModel):
+  name: str
+  age: int
+
+async def request_input_node(
+    ctx: Context,
+    node_input: Any,
+) -> AsyncGenerator[Any, None]:
+  """A simple node that requests input from the user."""
+  # Yield RequestInput to pause and request user details.
+  # The response must conform to UserDetails schema.
+  yield RequestInput(
+      interrupt_id="get-user-details-1",
+      message="Please provide user details.",
+      response_schema=UserDetails,
+  )
+```
+
+## How it works
+
+When a node yields a `RequestInput` object, the following process occurs:
+
+1. **Workflow Pause**: The workflow engine detects the `RequestInput` event and pauses the execution of the workflow.
+2. **Event Translation**: The `RequestInput` is wrapped into an `Event` containing a mock function call named `adk_request_input`. The fields `message`, `payload`, and `response_schema` are passed as arguments to this function call.
+3. **Client Interaction**: The client application receiving this event displays the message to the user (optionally validating the input against the provided `response_schema`).
+4. **Resuming execution**: To resume the workflow, the client sends back a `FunctionResponse` matching the `interrupt_id` (used as the function call `id`) and named `adk_request_input`. The response payload is placed inside the `response` dictionary.
+5. **Resume**: The workflow engine delivers this response back to the node, allowing it to continue execution.
+
+## Limitations
+
+- **Client-Side Validation**: When using `response_schema`, the client application is responsible for validating that the user's input conforms to the schema before sending it back to resume the workflow. ADK handles parsing on resume, but client-side validation is recommended for a better user experience.