Allow configuration of batch size (MaxElements) and pull timeout (MaxTime) for WQL/WinRM queries

[kegorof]

When executing WQL queries to fetch high-volume logs (such as Windows Security Logs) in certain environments, the library currently retrieves messages one by one. Because of this single-element polling behavior, large queries frequently hit a timeout before completing.

While this could theoretically be adjusted on the Windows host side, a cleaner and more robust solution is to allow the client library to configure batch sizing and pull timeouts directly within the WS-Management protocol layer via the MaxElements and MaxTime elements.

Current Behavior
The library issues enumeration and pull requests without explicit batch size limits, causing the host to default to a single-item delivery or unoptimized streaming that results in connection timeouts on large datasets.

Proposed Solution
Expose configuration options in the library to let users define:

1. Batch Size (MaxElements): To optimize both the initial enumeration and subsequent pull requests.
2. Optimize Enumeration (OptimizeEnumeration): To signal the server to return the first batch of elements immediately within the initial enumeration response rather than waiting for a separate pull request.
3. Pull Timeout (MaxTime): To manage how long a pull request should wait.

Expected XML Payload Changes

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" 
    xmlns:wsen="http://schemas.xmlsoap.org/ws/2004/09/enumeration">
    ........
    <s:Body>
        <wsen:Enumerate>
            <wsen:OptimizeEnumeration />
            <wsen:MaxElements>100</wsman:MaxElements>
        </wsen:Enumerate>
    </s:Body>
</s:Envelope>

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" 
    xmlns:wsen="http://schemas.xmlsoap.org/ws/2004/09/enumeration">
    ........
    <s:Body>
        <wsen:Pull>
            <wsen:EnumerationContext>123</wsen:EnumerationContext>
            <wsen:MaxTime>P30S</wsen:MaxTime>
            <wsen:MaxElements>100</wsen:MaxElements>
        </wsen:Pull>
    </s:Body>
</s:Envelope>

Impact
Implementing these configurations will significantly improve performance and stability when fetching large event logs, preventing premature timeouts and reducing network overhead through proper message batching.

[kegorof]

Apologies if this overlaps with an existing issue. While it handles similar MaxElements problem, I wanted to specifically propose adding support for the wsen:OptimizeEnumeration and wsen:MaxTime elements, which I believe are key to fixing this behavior. Thank you!

[bertysentry]

Status update: #35 was closed as a duplicate of this issue, which now tracks all three knobs (MaxElements, OptimizeEnumeration, MaxTime).

Since 2.0.0 (CXF backend removed), the lightweight backend already sends OptimizeEnumeration + MaxElements=32000 on Enumerate and honors the caller's timeout as OperationTimeout on Enumerate/Pull — so the single-element polling and premature timeouts described here should already be dramatically improved. Item 2 of the proposal is therefore done; what remains is item 1 and 3: making batch size and pull timeout configurable.

The planned home for that configuration is the WQL operation builder of the new fluent API (#131): pageSize(int) (today's 32000 becomes the default) and pullTimeout(Duration). The lazy streaming variant (#111) will use the same knobs. Keeping this issue open so the implementing PR closes it.