Vitsliputsli

Очевидно никак, организовывайте ping и по тайм-ауту разрывайте соединение для таких случаев.

Никакими. Все "ужасные последствия" связаны с непониманием того, что делаешь, а никак не передачей по ссылке. К примеру, в ООП нельзя передавать кроме как по ссылке, но даже в крупных проектах "ужасных последствий" от этого не наступает. Целый ряд встроенных в php функций также используют передачу по ссылке, и если на них посмотреть, станет понятно, что это сделано абсолютно корректно.

Для меня return; это успешное окончание выполнения функции по задуманному плану.

Именно так, если от функции не требуется возвращать какое-то значение, то return вполне достаточно, либо его можно вообще опустить. Для таких функций выставляется возвращаемое значение void. Иной выход из нее - только Exception.

Ведь return; == return false;

И да, и нет. Вообще оператор == допустимо использовать только в крайних случаях, которые нужно обосновать. При нормальном сравнении ===, return не будет равен return false. Ваше равенство верно лишь потому, что php выполнил приведение типов перед сравнением.

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

Используйте raw-формат в Body

Да, нужно именно теоретическое понимание. Чтобы когда на ревью джуну скажут, что он нарушил Single Responsibility, он не просил объяснений о чем вообще идет речь и тем более на стал доказывать, что его решение лучше. Нормально, если джун несколько "плавает" в понимании этих принципов (четкое понимание придет с опытом), ненормально, если считает, что с него требуют что-то лишнее.

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

Не используйте глобальные переменные, а внедряйте зависимость, тогда сможете поменять объект и тестировать то, что нужно.

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

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

был затронут один и тот же файл, тогда производится решение конфликта, но решение конфликта создаёт Merge ветки dev в конфликтующую ветку.

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

У вас нет проверки на пустой массив, поэтому возвращает 0. Не хватает проверки на float, на null уже нет смысла проверять, а проверять на массив не нужно при каждой итерации.
Т.е. что-то вроде этого должно быть:

function sum($arr)
{
    if (!is_array($arr) || count($arr)===0) {
        return false;
    }
    $sum = 0;
    foreach ($arr as $value) {
        if (!is_int($value) && !is_float($value)) {
            return false;
        }
        $sum += $value;
    }
    return $sum;
}

На втором сервере неделя начинается с воскресенья, а не с понедельника. Вероятно там очень старая версия php, в современных версиях неделя всегда начинается с понедельника. Либо обновляйтесь, либо смотрите как переопределить первый день недели.

Зависит от "повседневных" задач. Если не столкнетесь с адептами логики в базе, то написание хранимых процедур не понадобится. Обработка на стороне приложения как правило дешевле, но фильтрация данных и агрегация чаще всего осуществляется на стороне СУБД. Кроме основных операторов SQL нужно понимание транзакций (в том числе их уровней), варианты хранения данных (таблицы связей, EAV и прочее), нормализация, связи (внешние ключи используются почти всегда), индексы (не только какие бывают, но и как организовано сбалансированное дерево b-tree, как влияет селективность на выборку), план запроса, оптимизатор и сбор статистики, какие бывают локи и из-за чего, и для каких изменений нужно снимать нагрузку. Ну и сопутствующие вещи - миграции, фикстуры, драйверы СУБД, подготовленные запросы, sql-инъекции и т.п. Для начала достаточно иметь общее теоретическое понимание этих вещей, реально будете их изучать на практике, в зависимости от проектов и их нагрузки с разной степенью глубины.

То что вы хотите не нужно делать через http, либо используйте web-socket, либо полностью перетащите этот функционал на фронт. Http предназначен для получения данных, а не отправки команд-сигналов с сервера. Манипуляции с ajax или переполнением буфера - также будут извращением.

Укажите в команде composer update только тот пакет, который требуется обновить.

слышал, что можно просто удалить .lock файл и сделать по новой composer install. Отличается ли данное поведение от того, что произойдет при composer update?

Не отличается, не обнаружив .lock файл composer выполнит update вместо install.

и по сути это все действия которые я должен сделать на продакшене в данном случае?

Да, но не делайте этого под нагрузкой, сперва собирайте, а потом перенаправляйте нагрузку на новый код. Используйте blue/green, контейнеры, как написал Иван Шумов, или просто симлинки на одной и той же машине.

Какие еще классы разных API? REST API - это механизм взаимодействия, это внутренняя реализация, которая почему-то вытащена на верхний уровень, до уровня контроллеров. У вас должны быть бизнесовые сущности, и к объектам этих сущностей применяйте Принципы. А уже на более низком уровне для передачи данных бизнесовых сущностей используйте объект класса RestAPI, в котором, разумеется, не должно быть никаких завязок на специфику выше стоящих бизнесовых сущностей.
Ваш метод send выглядит странно, зачем он вообще нужен? Динамические методы это очень неудобно, IDE по ним вам ничего не подскажет и придется разгадывать этот ребус самому, а ничего более этот метод не делает.

если value существует, берем значение из value, иначе приравниваем 0.

$value = $value ?? 0
как уже предложили, но к
value = value || 0
это отношения не имеет. || - это оператор дизъюнкции, но в php он возвращает тип bool в отличии от js.

Для разработки база должна разворачиваться из миграций, т.е. не должно быть никакой зависимости от прода. Если не используете их, то пора начать. Чтобы не писать их все с нуля, создайте дамп структуры и разворачивайте его, а новые изменения уже в миграциях. Необходимые для разработки и тестирования данные заполняйте фикстурами.
Что касается логов в базе, то нужно понимать, как вы их используете, и уже исходя из этого выбирать решение.