Дмитрий Добрышин

1. Научиться ботом отслеживать любые сообщения пользователей.
2. Научиться удалять сообщения.
3. Научиться выдавать разные командные кнопки в зависимости от полномочий в группе.
4. Научиться сохранять состояние по команде.
5. Научиться проверять состояние.
6. Объединить всё вышеописанное в единую фичу.

У вас IO-bound задача, а это значит:

1. Вам нужно асинхронное решение, которое позволит избавится от времени ожидание IO операций в основном цикле программы.
   
2. Необходимо знать максимальное время обработки ответа (назовём его response_processing_time).
   
3. Необходимо знать минимальное время запроса (timeout) - время, в течении которого удалённый сервер не оборвёт связь (пусть будет request_time_out).

Последние два параметра связаны: response_processing_time > request_time_out * количество_запросов. То есть, если вы обрабатываете ответ сервера за 1мс или, другими словами обрабатываете 1000 запросов в секунду, это значит, что для тысячи запросов время соединения не должно быть меньше секунды. Для 5000 одновременных запросов - 5 секунд соответственно.
Это ограничение фундаментально и обойти его не получиться - можно только оптимизировать: или железом - задействовать дополнительные ядра процессора и/или программно - уменьшением времени обработки запроса.
Очевидно, что эти расчёты верны только для постоянного потока запросов, если у вас возможны паузы между запросами, то их надо вносить как поправочные коэффициенты.

Касательно сути вопроса - на чём лучше делать, я бы рекомендовал Go - идеальный язык для всяких сетевых штук, можно сказать, это его родная стихия. Тем более, что задача простая и её реализация не должна занять много времени даже для человека, который никогда с GoLang дела не имел.

Распараллелить выполнение в самом воркере с помощью ReactPHP или лучше GuzzleAsync. В таком случае не придется держать 5000 воркеров именно

Вариант с GuzzleAsync - самый лучший. Под капотом он использует возможности curl_multi_exec, которые позволяют асинхронно отправлять несколько запросов, не плодя при этом лишние процессы. Не уверен конечно, что осилит 5000 параллельных запросов, но даже если и не сможет, то можно разделить 5000 между несколькими воркерами.

2. "Правильно ли" это вообще делать с помощью PHP или это все таки задача уже других языков которые умеют в параллельное выполнение, корутины? Go, NodeJs?

У вас нагрузка в основном IO bound, так что не имет значения какой язык выбрать. Главное чтобы он поддерживал IO multiplexing (который поддерживается в PHP через вышеупомянутый curl_multi_exec).

3. Может уже есть готовые решения в виде библиотек на PHP? Искал, но не нашел

Guzzle

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

Важные данные обычно никогда не хранятся на клиенте, они передаются, используются и удаляются.

Есть ли какие-то ситуации, когда использование httpOnly сессионной куки нас защищает, а вот использование localStorage и sessionStorage уязвимо?

Если есть компроментация клиента, то никак не защищает. Единственное место, это где JS вообще в принципе не используется, т.е. клиенты с отключенным JS. Ну это как в рыцарских доспехах ходить по улице. Неудобно, но вроде как защищает от меча. Только с мечом уже давно не ходят, все больше с автоматами.

Теперь про токены. Токены в теории лучше всего держать не в localStorage, а в sessionStorage. Это хранилище переживает перезагрузки страниц и не расшарено между табами. Т.е. при открытии того же самого адреса в новом табе будет созданая новая сессия. Хранилище очищается при закрытии браузера и таба. Но это жутко неудобно, каждый раз логиниться. Поэтому здравая логика говорит об использовании localStorage, хотя если вы совсем отбитый, то можете хранить токен в сессионой куке.

Если вы прочли те статьи внимательно, то можно понять, что преимущества сессионных кук нивелируются неудобством их использования.
JWT Токены предназначены для микросервисной архитектуры. Т.е. у вас есть некоторый центр аутентификации, который выдает вам токен. Токен этот подписан относительно стойкой криптографией и постоянно ротируется.
Этот токен передается другим микросервисам, которые могут его верифицировать через публичные ключи (JWKS).
Т.е. если вы хотите, вы можете строить свои сервисы так, что они доверяют не только вашему центру аутентификации, но и гуглу с амазоном через OpenID. Есть ситуации, например когда вы хотите разрешить доступ к сервису сотрудникам другой компании. Например, когда такая компания огромна (десятки тысяч сотрудников). Они аутенфицируются у себя, а вы проверяете, что токен выпущен сервисом данной компании. Это не так сложно реализовать.
Реализация авторизации лежит на плечах каждого микросервиса и напрямую завязана на бизнес-логику. Как правило это некий внутренний микросервис, который интегрирован c middleware микросервиса.

В конфигурацию Yii2 добавьте transaction: false (https://codeception.com/for/yii)

array = list()
for x in root.xpath('.//tr'):
    a = x.xpath('.//td[2]')[0].text
    b = x.xpath('.//td[4]')[0].text
    array.append([a, b])

(\d+)\s*$

Откройте, пожалуйста, список символов в регулярных выражениях и прочитайте один, ровно ОДИН раз, полностью. Даже если вы не запомните всё с первого раза, то у вас в голове всё равно отложатся принципиальные возможности, которые можно будет подсмотреть при необходимости. Таких тупых вопросов:

В регулярке есть что-нибудь на тему пробела

больше не возникнет.

Существуют разные конструкторы для создания инсталляторов.
А уж какой именно вы создадите инсталлятор - это только от вас зависит.
Я обычно одностраничники делаю в Winrar.