ews: fix restriction relop element names (IsLessThanOrEqualTo/IsGreaterThanOrEqualTo)

[nourdineb-ops]

Problem

Enum::RestrictionRelop (exch/ews/enums.hpp) lists IsLessThanOrEqual/IsGreaterThanOrEqual, missing the trailing To that the real EWS schema element names have (IsLessThanOrEqualTo/IsGreaterThanOrEqualTo). Since StrEnum matches directly against the incoming XML element name (via tRestriction::deserialize() → Enum::RestrictionRelop(name).index()), any client using the correctly-spelled real element name gets rejected:

<m:FindItemResponseMessage ResponseClass="Error">
  <m:MessageText>E-3220: unknown restriction type 'IsLessThanOrEqualTo'</m:MessageText>
  <m:ResponseCode>ErrorInvalidRestriction</m:ResponseCode>
</m:FindItemResponseMessage>

This is a normal HTTP 200 EWS-level fault (ResponseClass="Error" inside a successful SOAP response), not an HTTP-level error - invisible to nginx/HTTP access logs and to gromox-http's own dispatch-level "unknown request" warning path, which only fires for unrecognized operation names, not unrecognized restriction element names within an otherwise-valid FindItem. Only a full request/response body capture surfaces it.

Real-world impact

New Outlook for Mac paginates a folder's item list backward in time via repeated FindItem calls using a date-cursor style: IndexedPageItemView MaxEntriesReturned="100" Offset="0" BasePoint="Beginning", sorted descending by item:DateTimeReceived, restricted with IsLessThanOrEqualTo against the timestamp of the oldest currently-loaded item. Every such call fails with the fault above; Outlook silently gives up (no error surfaced to the user) instead of retrying or reporting anything. Symptom: initial sync loads recent mail fine, but scrolling back further ("there are more items on the server" / conversation "load more") never brings in anything older, indefinitely - looks like data loss, but every item is still present server-side and reachable via search (FindItem with other restriction types still works).

Fix

Rename the two enum values (and their STR() string literals, which are stringified from the symbol name) to match the actual schema spelling. Verified against Microsoft's EWS SearchExpression/RestrictionType reference - the complete comparison set is IsEqualTo, IsGreaterThan, IsGreaterThanOrEqualTo, IsLessThan, IsLessThanOrEqualTo, IsNotEqualTo (plus And/Or/Contains/Excludes/Exists/Not, handled separately and already correctly named) - no other entries in this family are affected.

Testing

Reproduced live via a supervised mitmproxy capture of the actual failing FindItem request/response pair from a real Outlook client hitting a production gromox-http instance. Rebuilt exch/ews with this change, redeployed libgromox_ews.so, restarted gromox-http: the same restriction no longer errors, and the user confirmed older mail now loads correctly on scroll in Outlook.

[nourdineb-ops]

Following up — this has been open two weeks with no comments. Small, self-contained fix (two misspelled restriction relop element names, breaks New Outlook's date-cursor FindItem pagination silently). Let me know if anything needs more context.