Support ServiceLifecycle

[tixster]

В этом PR предлагаю добавить опциональную интеграцию TGBot с ServiceLifecycle.

Основная идея - дать боту нормальный lifecycle как у долгоживущего server-side сервиса. Вместо ручного start() где-то при запуске приложения и отдельного stop() при завершении процесса, бота можно подключить как Service: он сам стартует, ждёт graceful shutdown и корректно останавливается.

Это особенно полезно для long polling, потому что long polling по сути и есть долгоживущий background service. Такой подход лучше ложится на server-side Swift приложения: бот становится частью общего lifecycle, а не отдельной задачей, которую нужно не забыть запустить и остановить вручную.

ServiceLifecycle добавлен как SPM trait, поэтому эта интеграция остаётся opt-in. Пользователи, которым она нужна, включают trait ServiceLifecycle и получают TGBot: Service. Остальные продолжают использовать core SDK без обязательного линкования ServiceLifecycle.

Плюсы:

• TGBot можно запускать как обычный Service;
• graceful shutdown становится частью API, а не ручной логикой в каждом приложении;
• меньше риска забыть вызвать stop() при завершении процесса;
• long polling получает естественную модель запуска и остановки;
• ServiceLifecycle не навязывается всем пользователям SDK;
• зависимость остаётся опциональной через SPM trait.

Также в примере обновлена схема webhook processing: входящие updates складываются в bounded queue и обрабатываются отдельным сервисом. Это позволяет при shutdown остановить приём новых updates, дочитать уже buffered updates и только потом завершить работу бота.

[nerzh]

Привет, не мог ответить... Я пока бегло посмотрел и не совсем понял, какую проблему это решает. Наоборот, увидел что в примерах ты, как я понимаю используешь лонгполлинг ? Но тогда вообще зачем нужен вапор, хаммерберд и тд, а если вебсервер все-таки используется, то зачем в таком случае использовать тормозящий лонгполинг еще и как отдельный процесс внутри вебсервера ? Лонгполлинг это не продакшн протокол для телеграм, это всего лишь для тестирования при разработке. Он сильно ограничен по количеству запросов и скорости. Я понимаю, что его используют для небольших ботов, но это не означает, что вокруг лонгполлинга надо строить инфраструктуру. Вебхуки же наоборот дают возможность стабильно и быстро работать при умеренных нагрузках. ограничения можно почитать на сайте телеграма. В итоге код усложнился, но мне кажется он решает в итоге проблему, которой нет ? Возможно, я что-то не так понял, тогда объясни как-то более предметно на каком-то примере