Игорь Русинов

Если речь идет именно о php-сессиях, то информация о них хранится на сервере, и соответственно ее нельзя подставить в запрос извне. Другой вопрос, что часто под сессией подразумевается авторизационная сессия, когда вы храните куку, по которой сервер получает информацию о пользователе и дает доступ к сайту. В таком случае, если украсть такую куку и установить ее для сайта в своем браузере, вы можете получить доступ к аккаунту пользователя.

Использование репозиториев является альтернативой ORM, то есть в этом случае модель Category не должна иметь методов получения или сохранения себя в БД.
Ваш пример будет выглядеть следующим образом:

class CategoryRepository
{
    /*
     * @return Category[]
    */
    public function getAllCategories()
    {
        // Извлекаем категории из БД и создаем массив моделей Category
        return $categories;
    }
}

Соответственно для сохранения категории ваш сервис должен иметь метод CategoryService::save(), в котором будут выполняться необходимые проверки и подготовка данных, а затем вызываться метод репозитория CategoryRepository::save(Category $category).

$quotes = ['1a', '1b', '1c'];
echo $quotes[mt_rand(0, count($quotes) - 1)];
...
$quotes = ['2a', '2b', '2c'];
echo $quotes[mt_rand(0, count($quotes) - 1)];
...
и т.д., тоесть нужно заново инициировать массив

Предполагаю, что 5-6 Мб на процесс не так и много, эту память могут просто занимать загруженные библиотеки и модули вашего приложения. Для проверки этой гипотезы создайте скрипт с загрузкой тех же библиотек, что используется в ваших фоновых скриптах, но не извлекающий ничего из базы данных, и замерьте использование памяти. Но, если скрипты начинают использовать больше памяти со временем, то возможно вы не очищаете какие то переменные, например есть массив, в который складываются какие-то данные на каждой итерации, но не очищаются в конце. В таком случае, я думаю, что проблему нужно искать в вашем коде.

Если нужно именно эмулировать поведение пользователя и именно с php, советую присмотреться к Codeсeption с его PhpBrowser (https://www.toptal.com/php/php-testing-with-codeception - по ссылке есть пример с заполнением и отправкой формы).

Что вы подразумеваете под неблокирующим ожиданием? Если подключились - проверили сообщения - отключились - то это предполагает, что такую операцию нужно производить с определенной периодичностью, тогда смысл RabbitMQ в данном сценарии теряется, т.к. можно через определенный интервал времени проверять новые сообщения сразу в СУБД например.
Что касается сообщений и RabbitMQ, то можно создавать 2 очереди, (одну для передачи сообщений, другую для получения). Соответственно для получения сообщений подключаемся к очереди, слушаем из нее сообщения и при получении выдаем пользователю. Для отправки сообщений шлем отдельный запрос во вторую очередь, тут блокировки не будет.