Add SSE support to MockClient

[codingkiddo]

Summary

Adds basic Server-Sent Events support to MockClient.

Motivation

MockClient previously did not support SSE requests. The SSE methods returned null or an empty stream, so Unirest.sse(...).connect(...) could not be tested with mock expectations.

Fixes #570.

Changes

• Treats mocked SSE requests as GET requests for expectation matching.
• Supports SSE responses through the existing expect(...).thenReturn(...) API.
• Parses text/event-stream response bodies into Event objects.
• Supports both stream-based and handler-based SSE consumption.
• Adds regression coverage for mocked SSE events.

Testing

mvn -pl unirest-modules-mocks -am test

[ryber]

So, I think we want to do a few things here:

1. Its not obvious from the outside that Unrest::sseends up doing a GET on the URL, so I expect the MockClient to have a method that explicitly is for SSE. It's fine if internally it sets up the GET, but from the outside the MockClient should have the same convenience as the real client.

2. Users should not be expected to understand the raw formal of SSE streams. They should not expect to set delimitation or other formatting things about SSE. So the .thenReturns should accept an object or list of objects that define objects and the bodies.

Something like (and this is sudo code). In this example "EventStream" is an object that the user can feed more events to and it will stream out. I would look at how WebSockets are done. I would expect something similar.:

    client.expectSSE("http://events")
              .thenReturn(EventStream.of(
                   new Event("greeting", "hello"),
                   new Event("greeting", "world")
               ));

[codingkiddo]

So, I think we want to do a few things here:

1. Its not obvious from the outside that Unrest::sseends up doing a GET on the URL, so I expect the MockClient to have a method that explicitly is for SSE. It's fine if internally it sets up the GET, but from the outside the MockClient should have the same convenience as the real client.
2. Users should not be expected to understand the raw formal of SSE streams. They should not expect to set delimitation or other formatting things about SSE. So the .thenReturns should accept an object or list of objects that define objects and the bodies.

Something like (and this is sudo code). In this example "EventStream" is an object that the user can feed more events to and it will stream out. I would look at how WebSockets are done. I would expect something similar.:

    client.expectSSE("http://events")
              .thenReturn(EventStream.of(
                   new Event("greeting", "hello"),
                   new Event("greeting", "world")
               ));

Thanks, that makes sense.

I’ll rework this so the public API is explicit for SSE instead of requiring users to know that SSE is matched as a GET internally.

My next approach will be:

• Add a MockClient.expectSSE(String url) convenience method.
• Add an EventStream helper for mocked SSE responses.
• Support thenReturn(EventStream.of(...)) / event-object based responses instead of requiring callers to provide raw text/event-stream formatted strings.
• Keep the GET-based matching internal to MockClient.

I’ll update the tests to cover the new public API.