Vitsliputsli

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

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

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

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

Ведь return; == return false;

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

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

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

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

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

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

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

У вас нет проверки на пустой массив, поэтому возвращает 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, в современных версиях неделя всегда начинается с понедельника. Либо обновляйтесь, либо смотрите как переопределить первый день недели.

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

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

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

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

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

Можно ли подключиться один раз к базе mysql и дальше делать с этой базой любые запросы?

Можно.

Если "документы .php" - это файлы используемые одним процессом php, то только так и надо. Если нужно чтобы разные процессы использовали одно подключение к БД, то это вопрос не к php, а к тому кто будет поддерживать это соединение и шарить на процессы php. Есть persistent connection на стороне СУБД, но его лучше не использовать, т.к. не всегда оно корректно работает. Есть всякие ProxySQL которые могут это организовать, это и есть оптимальный вариант.

Как и написано в ошибке: An iterator cannot be used with foreach by reference - итератор не может использоваться в foreach через ссылку.
mysqli_query возвращает итерируемый объект, т.е. объект, который имеет метод для получения итератора, который знает как итерировать объект. При итерации foreach обращается к соответствующему методу итератора, который возвращает нужное значение. Т.к. это просто значение, а не свойство объекта, обратиться по ссылке к нему не получится.

Почему если fread() стоит раньше шем fwrite(), то консоль вообще ничего не показывает. А если fread поставить ниже fwite() то консоль выводит $msg.

Вы запускаете сервер и он ждет подключения. Запускаете клиент он подключается к серверу. Затем сервер начинает слушать сокет $msg=fread($connect,1024). Если клиент после подключения сделает fwrite($socket_client,$ENQ), то отправит на сервер строку $ENQ, сервер примет ее, выведет на экран и закроет соединение. Если вместо fwrite напишите $msg= fread($socket_client, 1024), то клиент будет слушать сокет. В итоге, сервер и клиент оба слушают, оба ждут передачи, а так как никто из них ничего не шлет, то будут это делать до бесконечности.

Вы описываете 2 стандартных подхода:
1) падаем в ошибку при любой непонятной ситуации;
2) при непонятной ситуации пробуем продолжить работу, если это возможно.
1 подход применяется в тех местах которые работают критически важными бизнесово данными. 2 подход для маловажных вещей, которые не способны исказить вещи из предыдущего предложения.
Т.е. в большинстве случаев нужно падать в ошибку, и только если знаете, что ошибка не несет никакого серьезного аффекта (к примеру выводить текст на экран жирным шрифтом или нет), то можно продолжать работу.