Add zerg, fix Unhinged content length calculation

[MDA2AV]

Add zerg c# framework (io-uring high perf)

Fix Unhinged content-length header calculation every request back to realistic

[github-actions]

The following frameworks were updated, pinging maintainers:
wiredio: @MDA2AV
zerg: @MDA2AV

[msmith-techempower]

This is a truly bizarre way to calculate the content-length of a response, and I don't think it really matches the spirit of what we're trying to get at with the "Realistic" classification. A truly "Realistic" approach to all tests other than plaintext would be not writing the headers at all and leveraging the framework to do that work.

It looks like you're writing 2 spaces in the content-length header, writing the body, then overwriting those two spaces with the "tens" and "ones" places that you get from the bytes committed. It's clever, but I am left asking the question of why this is necessary and whether the author intends end-users (e.g., developers) to perform this exercise on a realistic project.

I'm not going to accept this PR as-is. For one, this does not generalize to payloads over 100 bytes. That said, I went in search of better examples of "Realistic" implementations and found essentially everyone computing and specifying their own content-length (which, again, I think is an absurd expectation for end-users but whatever), so I'll say this: if you rearrange this to serialize the json message before constructing the headers, and use the length of that serialization in the header, then send the entire response, then I will consider it "Realistic" alongside its peers who do the same. Looking at spring as a simple example of what I mean.

Personally, I think it should be more like Gemini which simply calls the framework's json method and allows that to compute and set content length as well as other headers, but I'm biased.

[MDA2AV]

I have to indeed agree with you that it is somewhat of a fishy implementation.. but because it only supports content length up to 99. That can be fixed easily by simply leaving more spaces in the Content-Length header, or to be more fair, leave 10 zeroes like Content-Length: 0000000000\r\n, left trailing zeroes are (surprisingly) valid.

Again, I appreciate you guys actually reviewing the entries and I am not here trying to jeopardize anything, in fact I believe that every framework should work as you mentioned - no hardcoded or manually writing headers and would 100% love if that is the only acceptable format, however since it isn't I am forced to do this to be able to achieve the same or higher throughput as other frameworks that also do it.

if you rearrange this to serialize the json message before constructing the headers, and use the length of that serialization in the header, then send the entire response, then I will consider it "Realistic" alongside its peers who do the same.

So, this is a little bit unfair and let me explain why, I built both the epoll and io_uring engines from scratch to leverage low level access and manipulation on the write buffers, otherwise it would not be possible to do this as we need the exact pointer location on the write buffer even when flushing multiple responses at once in pipelined case.

Now, I also have to agree that for a user to have to do write such code it makes no sense so here is my proposal - I'll add a generalized helper to the framework that hides this mechanism from the user so that any length json is supported and user does not have to care about low level details, also this is marked as a platform framework so "(not actually a framework at all)", this is an engine other frameworks use and this entry serves as a benchmark to compare the engine performance without framework overhead.

Again, thanks for the time and effort on this

[msmith-techempower]

I get that, but if you want to get it merged in as-is you'll have to mark it "Stripped". It will still be shown in the results, but hidden by default.

[MDA2AV]

I will adjust this to let the framework calculate the content-length as other frameworks