Отключение IDisposable

Всё это не очень по нескольким причинам

1. Дизайн. Наследование от IDisposable другим интерфейсом постулирует нам о необходимости реализации интерфейса как нечто, что имеет высвобождаемые ресурсы. Плохая идея думать, что все реализации интерфейса «соединение» должны высвобождать ресурсы (есть тесты, как минимум). Следовательно, реализация IDisposable это необходимость для конкретного класса (например, SqlConnection и т.д.), а не интерфейса.

2. Существует композиция и аггрегация. При аггрегации время жизни вашего объекта определяет внешний контекст, а не класс где вы его используете (это свойство композиции). Вы описываете аггрегацию.

3. Большинство контейнеров зависимостей реализуют правила 3R: Register, Resolve, Release. Это, в том числе, значит, что контейнер может вызвать Dispose после окончания времени жизни объекта (Scope)

Собственно, решение можно подсмотреть у любого контекста подобного рода, например EF, где контекст регистрируется один на запрос (PerRequest) в случае веба. Либо использует пул/фабрику. Конкретная реализация будет зависить от конкретного кода.

они внутри себя могут реализовать IDisposable, где вызвать Dispose

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