Андрей Николаев

Во-первых, не ясно почему в таблице встречаются дубли, да еще и на колонке id.
Де-факто во всех проектах, что я видел, при наличии этого поля оно уникально (как минимум autoincement).

Во-вторых, подобный вопрос легко ищется поисковиком. Например тут.
Если хотите узнать больше, гуглите "Составной первичный ключ mysql"

У нас стартовая для виртуального сервера:
- 4GB RAM
- 2vCPU 2.4 (min)
- 20GB SSD
- KVM (не OpenVZ!)
В год выходит около 12 тысяч.

Дополнительно берем: Selectel (обачно хранилище).
Туда КП сгружает все загруженные/сгенерированные пользователем данные. У нас там порядка 80ГБ уже, и в год все это счастье ест где-то 2-3 тыс.руб.

Всего весь портал ест где-то 15 тыс. рублей в год.

Если стандартные возможности CRM полностью устраивают и доработок не требуется, то лучше с облака и не съезжать.

P.S. Если нужные собственные модули/разработки, то окупается во много раз

Нормально это не будет работать никак.

Для того, чтобы это хоть как-то работало нужно соблюсти ряд условий и ограничений:
1) Вы должны хорошо разбираться в nginx, чтобы развести root path в зависимости от адреса домена. Вы же не подумали, какая админка должна открываться по /bitrix/ ? Это уже не типовая конфигурация, которую Вам, к слову, еще и поддерживать.
2) Вы забудете об авторизации, то есть пользователь одного сайта это не пользователь другого сайта и переходя между страницами Вы потеряете авторизацию, ровно как и часть действий будет недоступна (например с сайта 1 вы не сможете редактировать статью У если она не на сайте 1, а на сайте 2, соответственно сайт 1 не будет видеть статей сайта 2 и наоборот). То есть - вся динамическая информация (записи инфоблоков и т.п.) должна переносится сразу (а не по 1-2 элемента)
3) Помимо этого еще и системные скрипты будут некорректно работать. Если на сайте нет авторизации, и только гости, то проблем вообще не будет, а если Вы таким образом захотите обновить интернет магазин, то займет это у Вас и времени и сил больше, чем написать с 0 новый и разработать скрипт миграции данных.

ИМХО, Ваша затея имеет место быть но в оочень редком случае (меньше 0.01%), а неудобств и ограничений Вы получите существенно больше.
Поверьте, я знаю о чем говорю - мы обслуживали 2 портала Битиркс24 (коробочная версия), на одном из которых Была 15 версия с CRM, а на другом 17 с остальной частью портала.

Ну... все относительно просто.

1) Изучаете API Хорошопа (на уровне "посмотреть что может")
2) Изучаете API Битрикс24 (на уровне "посмотреть что может")
3) Определяете что именно из Хорошопа должно уйти в Битрикс24 и что должно уходить из Б24 в Хорошоп.
4) Покупаете сервер, к нему домен и ssl сертификат. Устаналиваете все что необходимо для работы (например nginx, php, mysql и т.п.).
5) Пишете приложение обмена. Сначала в одну сторону (Хорошоп - Битрикс), потом если нужно - в другую.

Эм... есть несколько вопросов по Вашему "чуду".
Отбросив велосипедизм и костылестроение есть пара вопросов по логике работы.

То что у Вас есть константа MAX_AGE_IN_YEARS (кстати почемы бы просто не спрашивать дату рождения?) это ок (смущает конечно _IN_YEARS, но да ладно), то что у Вас 3 пола это тоже допустимо (по крайней мере в нашей адекватной России), то что у Вас есть допустимый ростовой диапазон тоже, но во чего я точно не могу понять, так это блин STATUSES.

Почему бы не сделать 2 "статуса" (на самом деле эт о скорее "признак жизни субьекта") - DEAD или ALIVE, то есть живой или не живой.
child, adult, old и т.п. можно получить при помощи отдельного метода исходя из возраста обьекта (ведь они же зависят от возраста, а не от каких либо правил).
"Статусы" buried и cremated это не статусы, а виды погребения.

Велосипедизм вызван именно нежеланием разделять физические сущности на их логические составляющие.

Почему бы не описать это при помощи сеттеров (т.е. в момент установки параметра, проверять его ошибки)? Почему бы не разделить это все на части и не хранить отдельно?

1) Проверьте настройки складского учета и что-то я не вижу класса провайдера при создании товара. Вы его передаете? Проверьте актуальные данные тут - https://dev.1c-bitrix.ru/community/blogs/vws/about...
2) А в paymentCollection после изменения цены все норм?

Проверьте директиву allow_url_fopen в php.ini.

Подробнее тут.
Если коротко:

Если во всех случаях у вас не приводимое к false состоянию, то можно сделать так:

var[0] = var[0] || 'default1';
var[1] = var[1] || 'default2';
var[2] = var[2] || 'default3';

Ну или проверять на typeof var[0] == 'undefined'.

Подскажите как применить класс ко всем страницам раздела.

1) А не открывали ли Вы страницы ранее? Т.е. не закешировались ли предыдущие страницы? Пробовали сбрасывать кеш?
2) Как именно вы подключаете свой стиль? Через inline, подключением файла или как-то по другому?
3) Вы применяете к однотипным страницам? Или к разным?

Собственно битрикс к этому вопросу имеет весьма посредственное отношение и вопрос тут гораздо глубже: как вообще находить дублирование информации на сайте.
Почитайте про grep

Добавляя к ответу Егор Скороходов, если уж очень не хочется работать с ManyToMany-моделями, есть более простой способ (как заплатка подойдет, но в перспективе будет хуже).
В SQL есть такая штука - FIND_IN_SET и можете воспользоваться ею.

Загрузка файлов
Для отправки почты использовать что-нибудь попроще: PHPMailer или Swift Mailer

Неплохо было бы почитать по Чистый код на php и PHP: The Right Way

Да тут по сути пара вариантов и есть:
1) Либо запросы проксируются (пропускаются) через СА к внутренним ресурсам. Тогда СА является единой точкой доступа к сети.
2) Либо запросы идут к конкретным ресурсам, а они уже опрашивают СА на предмет - правильный ли этот токен.

Я мало где видел второй вариант, посколько использовать одну точку доступа и на ней же располагать СА куда проще и выгоднее (нет лишних запросов по сети и время ожидания меньше).