fix(fpc): remove keepalive — fphttpserver poll interval causes ~40ms per-request stall

[freitasjca]

Summary

FPC-KEEPALIVE-1 enabled KeepConnections=True on the embedded fphttpserver to restore HTTP/1.1 keep-alive semantics. This produces a ~40 ms stall on every request — a 93× regression on Linux affecting every FPC user running Horse with the default provider.

Root cause

fphttpserver's TFPHTTPConnectionThread keep-alive loop calls select(fd, ~40 ms) between requests to poll for graceful-shutdown signals. Even when the next request is already queued, the loop waits one full interval. This is a fixed constant in fphttpserver — it cannot be configured from outside.

Evidence

Measured with h2load -n 50000 -c 1 on Linux (FPC trunk 3.3.1):

Condition	P50 latency	req/s
Before (keepalive on)	44 ms	0 (bench timeout)
After (keepalive off)	0.48 ms	1 459
Raw fphttpserver (no Horse)	0.41 ms	1 531

TCP_NODELAY was applied simultaneously and had zero effect, confirming the cause is the poll interval, not Nagle/delayed-ACK.

What this PR does

1. Removes EnableServerKeepAlive — KeepConnections reverts to False (fphttpserver default).
2. Adds EnableServerNoDelay (PATCH-FPCHTTP-2) — sets TCP_NODELAY on every accepted socket via TSocketServer.OnAllowConnect. Avoids Nagle on non-loopback links. Guard: FPC ≥ 3.3.1, UNIX only.
3. Adds FPCHttpKeepaliveTest.dpr — standalone FPC regression test: 30 sequential requests must complete in ≤ 35 ms each.

Trade-off

With KeepConnections=False, clients that reuse a connection after the server closes it receive ECONNRESET. Most clients (curl, browsers, System.Net.HttpClient) reconnect transparently. Connection pools that do not retry stale connections should be configured to do so, or to disable keep-alive with this provider.

[regyssilveira]

Obrigado pelos dados de desempenho e pela investigação do intervalo de aproximadamente 40 ms. Este PR ainda não está pronto para revisão porque mistura duas linhas de trabalho diferentes e altera a semântica HTTP/1.1 do provider padrão.

Antes de prosseguirmos, por favor:

1. Rebaseie sobre o master atual e remova todas as alterações relacionadas ao nghttp2. Este PR deve alterar somente Horse.Provider.FPC.HTTPApplication.pas, o teste específico e, se necessário, documentação diretamente relacionada ao keep-alive do fphttpserver.
2. Remova do histórico/diff as mudanças em Horse.pas, README.md e README.pt-BR.md que pertencem ao antigo PR de nghttp2.
3. Não desabilite keep-alive de forma incondicional. Isso evita o atraso, mas faz o servidor encerrar a conexão após cada resposta e pode causar ECONNRESET em clientes que reutilizam conexões. Prefira uma solução configurável, preservando a semântica HTTP/1.1, ou uma correção no mecanismo de espera do fphttpserver.
4. Explique como a resposta informa ao cliente que a conexão será encerrada. Se o servidor fechar sem Connection: close, o cliente pode tentar reutilizar um socket que parece persistente.
5. Substitua o limite absoluto de 35 ms do teste por uma verificação determinística ou comparativa. Esse limite pode falhar apenas por carga do runner, virtualização ou agendamento do sistema operacional.
6. Remova código morto após a solução final. No diff atual, EnableServerKeepAlive e DEFAULT_KEEPALIVE_TIMEOUT_MS continuam declarados/implementados apesar de não serem mais usados.
7. Separe o uso de TCP_NODELAY da correção do keep-alive ou demonstre por teste que ele é necessário. A própria descrição conclui que TCP_NODELAY não resolveu a regressão de 40 ms.

Depois da limpeza, precisamos reavaliar o trade-off entre latência, persistência HTTP/1.1 e compatibilidade dos clientes antes de aprovar.

[regyssilveira]

Obrigado pela investigação e pelos benchmarks apresentados. A alegação de latência com o keep-alive do fphttpserver é relevante e não está sendo descartada. Abrimos a issue #562 para reproduzir e identificar a causa de forma isolada.

Este PR, porém, não pode ser integrado no estado atual pelos seguintes motivos:

• remover KeepConnections faz o servidor fechar conexões HTTP/1.1 sem anunciar Connection: close, o que pode causar ECONNRESET em clientes com pool;
• o teste mede chamadas do TFPHTTPClient, mas não demonstra que todas reutilizam a mesma conexão TCP;
• o limite absoluto de 35 ms é sensível à carga e à virtualização do runner;
• TCP_NODELAY foi incluído embora o próprio diagnóstico conclua que ele não elimina o atraso;
• a atribuição de OnAllowConnect pode substituir um callback existente;
• permanecem código morto e mudanças não relacionadas no histórico/diff;
• a branch está conflitante com o master atual.

Além disso, a implementação do FPC usa Socket.CanRead(KeepConnectionTimeout), cujo timeout é um limite máximo e deveria retornar quando o socket se torna legível. Precisamos confirmar com conexão persistente comprovada, strace e captura de tráfego onde os ~40 ms são consumidos antes de escolher a solução.

Vamos continuar essa análise na #562. Se a causa for confirmada no Horse, faremos uma correção isolada, preservando a semântica HTTP/1.1; se estiver no fphttpserver, encaminharemos um reprodutor mínimo ao FPC upstream. Por isso, estou fechando este PR sem merge.