D3lphi

a mod b - это целочисленный остаток от деления числа a на b. Скорее, верно равенство [a/b] = a div b, если речь идет об операторе div в паскале.

const int MAX_LATENCY = 100;
int current_latency = MAX_LATENCY - x;

Этой записью в англоязычной литературе обозначают число сочетаний. Читается, как "число сочетаний из n по l". В русскоязычной литературе чаще встречается обозначение через C:

Прочитайте про то, что такое сокрытие.

"Java", которую вы загружаете с главной страницы - это и есть JRE.

getClass() возвращает объект типа Class<T>, по сути, этот объект представляет тип, который имеет какая либо сущность. Выполняется этот метод в рантайме.
Проверка типов же осуществляется на этапе компиляции.
Переменная a имеет тип A, поэтому для того, чтобы работать с этой переменной, как с объектом типа B вам нужно его явно привести к этому типу. Вы не сможете просто так без каста выполнить вызов a.testB() так как для компилятора этот объект имеет тип A (а в нем не существует метода с сигнатурой testB()).

Тем не менее, с помощью рефлексии вы можете вызвать метод динамически:

java.lang.reflect.Method method = a.getClass().getMethod("testB");
method.invoke(a);

Но в таком случае, вы лишаетесь проверки типов на этапе компиляции.

Есть такой плагин для composer'а - wikimedia/composer-merge-plugin. Он позволяет подключать к проекту локальные пакеты.

Composer.json при этом принимает примерно такой вид:

{
    "require": {
        "wikimedia/composer-merge-plugin": "dev-master"
    },
    "extra": {
        "merge-plugin": {
            "require": [
                "submodule/composer.json" // Путь до файла composer.json вашей библиотеки.
            ]
        }
    }
}

Теперь вы можете изменять исходный код вашей библиотеки и сразу довольствоваться результатом.

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

Задайте себе вопрос: "Является ли девайс сокетом?" и сразу все поймете.

Дабы пользователь не использовал какой-либо url в корыстных целях, все параметры запроса хэшируются с использованием секретного ключа, который есть только у сервиса оплаты (mysite1.com) и у сервиса-клиента (mysite.com). Когда происходит запрос, хэш вычисляется повторно и сверяется с тем, который пришел в запросе. При попытке всячески изменить значения параметров контрольные сумма будут не совпадать.

Есть подозрение что этот подход не верный

Абсолютно. Не понятно, чем вы руководствовались, когда писали статику, да ещё и в контроллере. Читаем, чтобы впредь не делать такого.

Выносите логику взаимодействия в классы-сервисы, в чем проблема-то? Разделяем саму логику взаимодействия - это инфраструктурный слой и обработку данных - это бизнес-логика.

Значит так, берем толстую тетрадь, ручку и пишем фразу "Статические методы не имеют отношения к ООП" до тех пор, пока не запомним это на всю жизнь.
Суть объектно ориентированного программирование, как понятно из названия, заключается в том, что должен существовать объект. Статика существует не в контексте объекта, а в контексте класса! Из этого вытекает то, что на протяжении всего жизненного цикла вашего кода будет существовать лишь одно глобальное состояние статических членов класса.

Использовать статику нужно в случае, если то, что вы ей описываете принадлежит всей группе объектов, а не одному. Например, у класса Human может быть статический метод numberOfLegs(), который возвращает количество ног у людей. Количество ног - это общее свойство для всех людей (Речь идет о здоровых людях). В данном случае можно было использовать константу класса, но это не так важно, ведь, по сути, константа - это тоже статический контекст. А вот имя - это уже свойство каждого отдельного человека. И очень важно чтобы статические методы не изменяли состояние системы в целом, не содержали побочных эффектов.
В статические методы можно выносить какую либо служебную логику. Например, метод перевода числа из арабской в римскую запись следует сделать статическим.

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

Большое количество. При чем, не таких уж и подводных. Из-за того, что статика глобальна, она плохо поддается тестированию, ее нельзя замокать. Глобальное состояние плохо поддается отладке. Отсутствует возможность подменить реализацию, так как это позволяют сделать объекты.

Вся работа с БД должна производиться в репозиториях.
Репозиторий работает с сущностями, так что, в случае использования active record ORM, из ar модели нужно будет создавать сущность и возвращать ее из репозитория. Не даем подключению к БД "гулять" по проекту. Entity это обычный popo в котором нет какой-либо логики, а есть лишь набор полей, геттеры, ну и методы для обновления состояния.

Например:

class EloquentUserRepository implements UserRepository
{
    public function findBySomething(string $something): ?UserEntity
    {
          $user = User::where('something', $something)->first();

          if ($user !== null) {
              return new UserEntity($user->id, $user->something);
          }

          return null;
    }
}

Может в строну доктрина копать?

Верное решение. Лучше откажитесь от eloquent и возьмите doctrine, если проект требует серьезной ORM.

Измениться может не длина хэша bcrypt, а алгоритм хэширования по-умолчанию (то есть, под PASSWORD_DEFAULT в новых версиях PHP могут подразумеваться алгоритмы, отличный от bcrypt).
Хэши нужно хранить в blob поле только, если сгенерированный хэш находится в бинарном представление (добиться этого можно, передав в функцию hash() последним параметром значение true). Bcrypt же представлен в символьном виде.

Итог: для хранения хэшей bcrypt используем поле VARCHAR(60), а лучше - CHAR(60) - так как строка имеет фиксированную длину.