Daria Motorina

Да, ответ оказался действительно проще чем казалось.

Достаточно было использовать форматер Monolog\Formatter\LineFormatter в конфиге и убрать лишние аргументы в нем.

attribute.logger.formatter:
    class: Monolog\Formatter\LineFormatter
    arguments: [ "%%message%% %%context%%\n" ]

F12. Раздел "Элементы", выбираете элемент, на котором нужно посмотреть обработчик события. В области интерфейса для просмотра свойств элемента выбираете вкладку "Прослушиватели событий". Выбираете вид события, и выбираете точку входа в JS коде на это событие. Далее, при просмотре кода JS на вкладке "Источники" выбираете, где вам поставить точки останова, чтобы словить остановку выполнения обработки события.
PS: Такой метод исследования работает только на ванильном или слабо прототипированном коде, написанный без применения библиотек и фреймворков. При использовании библиотек и фреймворков точки привязки событий будут указывать, как правило, на одну единственную функцию в этой библиотеке, отвечающей за высокоуровневый байндинг событий. В этом случае нужно изучать, какие инструменты для отладки есть в самой библиотеке или фреймворке.

Написано же в самом PSR-16:

PSR-6 solves this problem already, but in a rather formal and verbose way for what the most simple use cases need. This simpler approach aims to build a standardized streamlined interface for common cases. It is independent of PSR-6 but has been designed to make compatibility with PSR-6 as straightforward as possible.

Грубо говоря, 16 - это синтаксический сахар к 6.

вы, наверно,пишите на чем-то скриптовом, ибо 50к коннекшинов в сутки - вообще плевая задача
не плевая задача - организовать их доставку
даже не знаю, как покороче
гуглите , наверно, PowerMTA для начала https://www.sparkpost.com/powermta/
ну и чтобы два раза не вставать - сразу закупайтесь тут , тем более скидка на пятницу есть вроде еще

а так - в целом все правильно видите - насыпайте в очередь и обрабатываете, меняя доставщики в зависимости от...

Я значительно переработал этот ответ, поскольку мне самому не нравились некоторые моменты плюс я обратил внимание на конкретные примеры из вопроса.

В первую очередь, не надо путать потоки как принцип, абстракцию, и потоки как конкретную реализацию этого принципа в виде механизма потоков в РНР. При этом даже в этой конкретной реализации есть много нюансов, которые не всегда очевидны. Скажем, врапперы в РНР можно разделить на встроенные и пользовательские. Причем даже встроенные могут значительно отличаться по своей реализации.

Например, когда мы вызываем функцию fopen, то в результате мы получаем ресурс, который в себе содержит дескриптор файла, и далее мы уже можем работать с этим файлом не считывая его полностью в память.
Как я понимаю, через потоки.. но что это за потоки ? где именно про них почитать ? это какие-то механизмы операционной системы ?

Вот даже здесь, поскольку fopen работает поверх абстракции, нельзя говорить о едином подходе.
Если у нас самый простой случай - локальный файл - то РНР оборачивает функции для работы с файлами языка С в свою собственную абстракцию. Но ниже - на уровне этих самых функций языка С - никаких потоков нет. Есть обращение к функциям операционной системы, которые просто позволяют прочитать выбранный кусок файла.
Тут никаких вопросов нет, всё честно - если мы прочитали из файла 5 килобайт - значит потратили ровно 5 килобайт памяти.
Но работаем мы с файлом не считывая его весь в память не потому что поток, а потому что так устроена файловая система. А поток этой возможностью только пользуется.

Если же мы открываем не файл, а URL, то РНР начинает извращаться, пытаясь предоставить те же самые инструменты, какие мы используем для работы с файлами, для доступа к ресурсам совершенно другого типа.
И здесь возможны нюансы. Я не знаю, как реализован HTTP wrapper, но в теории HTTP позволяет чтение произвольного объема данных через заголовок Range:. То есть РНР вполне может читать и из НТТР кусками, а не целиком.

В общем поток - это абстракция. Подход. Интерфейс. Способ работы с массивом информации не забирая её всю в память.
При этом реализация конкретного инструмента, использующего этот подход, может быть совершенно самостоятельной, никак с другими не связанной. Мне кажется, что именно этот момент является для вас камнем преткновения: на техническом уровне это совсем не обязательно одни и те же потоки. Но вполне могут быть.
При этом важно не смешивать сам поток и его получатель (получатель вполне может накапливать всю информацию из потока).

А упомянутый в вопросе PSR-7 вообще никакого отношения к потокам в РНР не имеет. Это совершенно отдельная реализация принципа потоков, которая не имеет отношения к потокам в РНР.

было много ПР в промежуточную ветку, их ревьюила команда, к которой принадлежит разраб который сделал ПР;
далее эти все коммиты/изменения были объединены в один ПР и он стал похож на страницу с содержанием книги с десятками коммитов, в то же время к ревью подключились разрабы из других комманд и ревью затягивается еще на несколько дней;

Вам нужно решить, где чья ответственность. В большой команде не может каждый разработчик читать код каждого другого разработчика. Поэтому нужно просто делать адекватные коммиты/мелкие ПР и ревьюить их, а если они уже поревьюены - то не обращать на них внимания, т.к. это теперь не ваша ответственность.

Почему вы повторно ревьюите этот же код, ещё и теперь объединённый в один большой ПР? Какой смысл? У вас что-то не так с организацией ответственности.

Вместо того чтобы делать почасовую проверку - просто записывай время покупки, и время действия премиума.
А когда чел делает запрос какой-нибудь штуки, которая требует премиум - проверяй, не истекло ли время.
Можно ещё кэшировать результат в какой-нибудь другой базе, чтобы не вычислять постоянно, - в том же редисе, например.

Pma и mysql в разных сетях. У pma так же должно быть

networks:
      - app-network

Или другая общая с mysql сеть

Парсер такое воспринимать не научен (да и писателю я бы по рукам надавал).
return $x[0]::{$x[1]}();
(это помимо того, что очевидно $x и $m перепутаны были после четвероточия)