BurstObservatory: add option to set http method for burst check

[Jolymmiles]

burstObservatory is unable to correctly detect certain local blocks in Russia, as the current implementation uses only HEAD requests, and the regular observatory does not read the response body or handle errors. This makes it impossible to detect blocks based on the size of downloaded data.

Problem:
Recently, certain types of blocking have been observed in Russia, where:

• A TCP connection is established.
• The 3-way handshake and TLS Client Hello complete successfully.
• After that, the connection hangs for 40–60 seconds and then ends with an RST.

Such connections are marked as alive in burstObservatory because the HEAD request does not trigger the block.

After thorough analysis, it was found that the block is triggered only when attempting to read the body of a GET request, and only if the body size is greater than or equal to 20 KB.

Solution:
The ping function in burstObservatory was modified:

1. An httpMethod option was added to allow choosing the request method.
2. Full body reading using io.ReadAll was implemented for GET requests, along with error handling.

For testing, a site was set up with the URL /slow-200 that returns a static 20 KB body.

Result (after modification):

[Warning] app/observatory/burst: error ping https://test.dev.com/slow-200 with CDN-PROXY: Get "https://test.dev.com/slow-200": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
[Warning] app/observatory/burst: error ping https://test.dev.com/slow-200 with ENTRY-PROXY: context deadline exceeded (Client.Timeout or context cancellation while reading body)

Before modification (HEAD request):

[Warning] app/observatory/burst: error ping https://test.dev.com/slow-200 with CDN-PROXY: Get "https://test.dev.com/slow-200": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

In the second case, the block is not detected, and observatory considers the connection available, which leads to routing traffic through a non-working outbound.

[Jolymmiles]

burstObservatory не способен корректно определить некоторые локальные блокировки в России, т.к. текущая реализация использует только HEAD-запросы, а обычная observatory не читает тело ответа и не обрабатывает ошибки. Это делает невозможным детектирование блокировок, основанных на отсечке по размеру загружаемых данных.
Проблема:
С недавнего времени, в РФ наблюдаются блокировки, при которых:
• Устанавливается TCP-соединение.
• Проходит 3-way handshake и TLS Client Hello.
• После чего соединение зависает на 40–60 секунд и завершается RST.
Такие подключения помечаются как alive в burstObservatory, так как HEAD-запрос не вызывает блокировки.
После тщательного анализа выяснилось, что блокировка срабатывает только при попытке прочитать тело GET-запроса, если оно превышает или равняется 20 KB.
Решение:
Была модифицирована функция ping в burstObservatory:

1. Добавлена опция httpMethod для выбора метода запроса.
2. Реализовано чтение тела до конца (io.ReadAll), с обработкой ошибок для GET запроса.
   Для тестов был поднят сайт с URL /slow-200, отдающий статическое тело размером 20KB.
   Результат (после модификации):
   [Warning] app/observatory/burst: error ping https://test.dev.com/slow-200 with CDN-PROXY: Get "https://test.dev.com/slow-200": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
   [Warning] app/observatory/burst: error ping https://test.dev.com/slow-200 with ENTRY-PROXY: context deadline exceeded (Client.Timeout or context cancellation while reading body)

До модификации (HEAD-запрос):
[Warning] app/observatory/burst: error ping https://test.dev.com/slow-200 with CDN-PROXY: Get "https://test.dev.com/slow-200": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
Во втором случае блокировка не фиксируется, и observatory считает соединение доступным, что приводит к маршрутизации трафика через нерабочий outbound.

[Fangliding]

protoc gen go version

[Jolymmiles]

protoc gen go version

yeah, because it in main branch

[Jolymmiles]

also

[Jolymmiles]

solved proto gen, but it required change core/proto.go

[Fangliding]

solved proto gen, but it required change core/proto.go

you can simply just not commit that file

[Jolymmiles]

@Fangliding could you look pls?

[Fangliding]

proto问题应该已经没有了
我不觉得我们应该为下载20kb后再阻断的神秘行为负责 不过加一个method应该是可以接受的 还有一个问题是是否只在get的时候尝试获得响应体
具体得看 @yuhan6665

[yuhan6665]

Thanks for your work! Looks good to me!

[yuhan6665]

BTW I agree with Fangliding that maybe better read body for any method except HEAD. But it is too minor we can do later so I merged it