Vitsliputsli

Но может ли вообще socket сервер на php обрабатывать http запросы?

Не может. Http и websocket - это 2 разных протокола.

Раз уже используется websocket, то логичнее его и использовать.

Непонятно о какой проблеме спрашиваете, но вероятно ищите это: curl-multi-init

1) Локальный сервер и CI/CD никак не связаны.
2) Вы можете написать свой CI/CD на js. Либо использовать любое популярное решение и из него запускать скрипты js, не встречал чтобы так делали, но почему бы и нет.
3) Разные проекты хранят в разных репозиториях, это основные принципы пользования системами контроля версий.
4) Обычно в готовых решениях есть автоматически формируемые списки изменений, по-сути список коммитов отличающих текущий билд от предыдущего. Но "до версии 1.0.0" это что-то странное, если только сами это сделаете.

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

Советовать что-либо сложно, т.к. на мой взгляд система странная. Обычно разные проекты располагаются в разных репозиториях, так удобнее. Версии вешают тегами и собирают билды зачастую именно по тегам, хотя бывает и по веткам тоже.
Ориентируясь на фразу "Делаю проект на NodeJS (бек+фронт), настал момент, когда нужно настроить автоматический сбор билдов" хочется спросить, а зачем вам вообще CI/CD, нужно автоматизировать сборку - автоматизируйте, зачем нужен CI/CD?

Если я правильно угадал, что требуется, то более-менее по-человечески будет выглядеть так:

function wr($data,$postfix) {
    return empty($data) ? null : ($data . $postfix);
}

wr($result,'Rent');

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

Все зависит от того что делаете. Если разрабатывает для nix-серверов, то рекомендуется использовать такую же систему для разработки, иначе вместо нормальной работы будете выдумывать костыли как обойти тот функционал, который в Windows не работает. Либо сразу создавайте виртуальные машины, linux в windows или иные решения.
Второй момент GNU-инструменты, но они уже портированы на Windows и там более менее нормально работают.
В остальном ваши личные предпочтения, например не хочется в 2020 году разбираться с кодировками, которые в Windows системе одна, в ее консоли другая, а нужно работать вообще с UTF-8. Или раздражает что система живет своей жизнью и вы ей никак не управляете. Или вы часто используете типичный для Windows софт, а в Linux это все придется запускать костылями, а то и вообще не получится.
Что значит, пока не попробуешь не узнаешь.

По-моему самое простое и правильное решение здесь - insert ignore, другой вариант транзакции с блокированием таблицы, но это может сильно ударить по производительности.

Аналогично, но в разы быстрее будет так:

SELECT 
            "ticker_symbol" AS symbol, 
	    count(case when "request_status" = :requestStatus then 1 else null end) "pendingCount",
	    sum(case when "request_status" = :requestStatus then "amount" else null end)::varchar "expected"
	FROM "requests"  
	WHERE "wallet_address" = :walletAddress 
	GROUP BY "ticker_symbol"

Если я ниего не напутал.
А если нулевые значения не нужны, то можно еще проще:

SELECT 
            "ticker_symbol" AS symbol, 
	    count(*) "pendingCount",
	    sum("amount")::varchar "expected"
	FROM "requests"  
	WHERE "wallet_address" = :walletAddress and "request_status" = :requestStatus
	GROUP BY "ticker_symbol"

if ($g1 = 1) {

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

trunc(t.start_date, '$g9')

не вставляйте значения напрямую в запрос, используйте подготовленные выражения https://www.php.net/manual/ru/function.oci-bind-by.... Скорее всего значения вставленные напрямую ломают синтаксис SQL из-за наличия кавычек.

Ну и ; не нужна в конце SQL запроса, это не PL.

как мне получит json
json_encode возвращает NULL

у вас и так почти json, нужно только добавить [ слева и ] справа.
Наверное имелся ввиду json_decode, а не json_encode?

В общем, в чем конкретно выигрыш от шардирования?

Шардирование не предназначено для ускорения доступа к данным, поэтому нет смысла сравнивать с индексами, во всяком случае не в таком контексте как вы описали. Шаридирование - это вариант горизонтального масштабирования. Когда вы не сможете больше увеличивать мощность одного сервера СУБД под возросшие потребности, то придется задуматься о нескольких серверах СУБД, т.е. о горизонтальном масштабировании, а шардирование один из его вариантов.

Warning: fsockopen(): unable to connect to ssl://smtp.gmail.com:465 (Network is unreachable) in /home/i1949615/public_html/parse/email.php on line 3
ERROR: smtp.gmail.com 465 - Network is unreachable (101)

как это решить?

Починить сеть.