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 перепутаны были после четвероточия)

Я бы использовал service locator для формирования списка сервисов и передавал его в конструктор фабрики.

Альтернативно можно определить фабрику как service subscriber, тогда формирование service locator'а будет, возможно, ещё проще.

Если же каким-то образом (например через общий интерфейс или статический метод класса-фабрики), определить список сервисов, которые умеет создавать фабрика, то можно создать compiler pass, который будет формировать service locator на этапе компиляции контейнера через анализ их зависимостей. Это чуть сложнее, но не потребует править код при расширении списка создаваемых фабрикой классов.