Vitsliputsli

Самый правильный вариант - отключаться, если соединение не используется. Правильно, т.к. не используем ресурсы для поддержания ненужного соединения, ни на клиенте, ни на сервере. И не ловим эксепшены.
И только если ну никак нельзя это контролировать, тогда реконнект по эксепшену.

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

do {
    $path = [key($array), $link = current($array)];
    while (isset($array[$link2 = $link])) {
        $link = $array[$link2];
        unset($array[$link2]);
        $pathPos = array_search($link,$path); // более для понятности, для длинных колец эффективнее хранить только ключи и искать по ним
        if (false !== $pathPos) {
            var_export(array_slice($path,$pathPos));
            break;
        }
        $path[] = $link;
    }
} while (false!==next($array));

Создать зависимость можно только 2 способами, получив объект изнутри или проведя инъекцию снаружи. Если изнутри, то так или иначе понадобится синглтон, если снаружи, то ктото снаружи должен контролировать передачу одного и того же объекта во все нуждающиеся объекты.

1. Изнутри. Очевидно просто инстанцировать объект - это очень плохой вариант. Более менее нормальный вариант, это сервис локатор, с методом возвращающим нужный объект работающим как синглтон (т.е. не нужен прям класс синглтона, только метод который проверяет существует ли объект). Выглядит это не очень, синглтон и сервис локатор не считают хорошим решением. Из минусов статичное обращение к сервис локатору создаст проблемы для подмены объекта. Для разных подключений вы можете создать отдельные методы сервис локатора или разрулить в одном методе динамический выбор. Реальная проблема - тестирование, вы не сможете мокировать объект работы с БД. Но, можно это сделать ухищрениями, сделав ленивое подключение, и метод подмены объекта БД, хотя придется этот метод тащить в каждый класс. Как вариант, делать инъекцию объекта сервис локатора. Но остается другой большой минус, сервис локатор "гвоздями прибит" к большинству классов и вам придется его везде таскать, т.е. о красивых компонентах без странной зависимости от сервис локатора можно забыть.
2. Снаружи. Оптимально, и считается трендом - инъекция нужного объекта в конструктор. Будет ли это делать DIC или чтото иное не имеет значения. Не нужно таскать какието дополнительные сервис локаторы. Но данное решение имеет тот же минус, что и п.1, вы не сможете подменить объект на другой при мокировании:
public function __construct(PDO $db)
внедряемый объект обязан быть классом PDO, если хочется чтобы мок просто подсовывал одни и те же значения нужно менять на интерфейс, тогда моку достаточно выполнять требования интерфейса. Но, если ваш DIC использует автоматическое определение требуемых объектов по структуре конструктора, то использовать интерфейс не получится.

Парсер просто последовательно читает текстовой файл, он ничего не знает о выполнении кода, но знает синтаксические правила языка. Если речь про интепретатор, то он выполняет код последовательно, но в нем есть команды перехода к различным участкам кода, от простейших условных и безусловных до функций и объектов с методами.
Поддержки асинхронности из коробки в php нет, но есть специальные библиотеки для этого, например ReactPHP. Если же говорить про чистый php, то в нем есть несколько асинхронных функций (например multi_curl), но правильнее сказать, что они неблокирующие, а асинхронность придется воплощать вручную, периодически передовая управление этим функциям.

никаких ошибок не выдает... Там просто в моменте обрывается и всё

Запускаете дебаггер и смотрите, что происходит. Если нельзя воспользоваться дебаггером, значит логируйте шаги выполнения, увеличивайте детализацию логирования пока не локализуете проблему.

Без этой информации можно лишь гадать, варианты:
1) скрипт выполняется корректно (например, у вас не 8к записей, читаете не из той БД, не с теми параметрами и т.п.);
2) происходит ошибка, но мы ее не видим (смотрим не в тот лог, гдето присобачен обработчик, который перехватывает ошибки и подавляет их сообщения, и т.п.);
3) скрипт действительно аварийно прерывается без каких либо сообщений об ошибках (значит чтото дает команду на это, если самовредительством не занимались, то остается только oom killer, но вряд ли у вас безлимит на память php, и то что закончилась память вы бы заметили, так что очень маловероятно);
4) неведомая хрень (баги в php, в ОС и хз что еще, еще менее вероятно, чем п3).

Приведите, пожалуйста, простой пример, как, именно «заменить» ключ (числовой на строковый) в массиве.

Если не вникая, на кой это нужно, то так:

unset($array[1]);
$array['first']=1;

Для массивов есть итератор foreach и не только, зачем вам ArrayIterator?

Используйте регулярные выражения, в зависимости от вариативности текста, от обобщенного:
/<b>(.*)<\/b>/
до более узкого:

/\(длина, ширина, высота\): <b>(\d+ x \d+ x \d+)<\/b> см. /

Берете транслятор, если на основе php, то например phplrt. И пишите грамматику вашего языка. Перед написанием рекомендую прочитать "книгу дракона", это прям библия компиляторов, как минимум главы про грамматику.

Почему следующий код на PHP печатает 7, а не 12?

Потому что это не js. А global работает ровно так как описано в доке, по-другому никак, т.к. область видимости работает иначе в языке.
А делать надо так, чтобы функция внутри себя не обращалась с произвольными данными извне, только с теми, которые вы заранее объявили. Только так можно контролировать код. А значит global не нужен.

Хочется вынести одно постоянно соединение api(или части запросов) на одно постоянное соединение. Остальной сайт и странички будут работать с множественными соединениями.

Выделите для api отдельный пул php-fpm воркеров из 1 штуки.

Я их ловлю не для того, чтобы вывести, а чтобы отправить себе в телеграм.

Тогда просто настройте парсинг логов. Держать такую логику в обработчике исключений сомнительная затея, не говоря уже о том, что ошибка может произойти до регистрации обработчика, или в самом обработчике.
А лучше настройте нормальную визуализацию ошибок, например Elastic+Kibana, а там уже по создавайте алерты по которым будут кидаться сообщения в телеграм. В сообщении будет просто ссылка на лог в Кибане, где можно будет увидеть не только ошибку, но и что ей предшествовало.

Если someFunction возвращает bool, то

if (someFunction(.....)) {
  doSomething();
}

Если не bool, то прописать условие.

Проверьте, эмулируйте соединения.
Скорее всего остановится в районе 1000. Тогда проверьте колво файловых дескрипторов на процесс. Либо увеличивайте их колво, либо запускайте несколько процессов, либо используйте другой язык.
10к-20к - это много для одного процесса, если подразумевается, что они все одновременно ломанутся за подключением, то большинство будет долго ждать, и не секунды, а минуты.
В коде логики практически нет, так что не должно из-за нее напрягаться. Хотя я особо не вчитывался, условия с неявными преобразованиями, ужасные названия переменных (типа $arrayCount[$items]) очень сильно мешают вникать.

Утечка - это когда процесс не пользуется памятью, но и не высвобождает. По вашему описанию, php-fpm прекрасно использует память для других скриптов, а также высвобождает при необходимости. Т.е. это не утечка.

Чтобы утечка проявила себя более явно установил memory_limit = 1G

Выделение памяти операционкой это медленный процесс, поэтому при возможности выгоднее запросить побольше, вы выставили лимит в 1G, почему бы не зарезервировать сразу 18%.

В общем, если без перезапуска php-fpm рано или поздно получите ошибку недостатка памяти, тогда можно будет говорить об утечке.