Когда File, File*Stream создаются через относительный путь, то в качестве корня используете "текущая директория" - "user.dir
User's current working directory" смотрите JavaDoc System.getProperties() и File

JEE приложения деплоятся куда угодно и сервера запускаются как попало. Соответственно использование user.dir стоит избегать.

Если у вас свойства меняются только в девмоде (т.е. после сборки тот кто отвечает за деплоймент их менять не должен) то оптимальный способ это метод Class.getResourceAsStream() - ваши свойства лежат с вашими классами и этот метод будет всегда работать, даже если код будет не в JEE приложении.

Соответсвенно недостаток этого подхода в том что свойства живут внутри war архива и менять их во время каждого деплоя геморно. Это относится и к db.properties. Вы сущетсвенно упростите процесс деплоймента если будете использовать JNDI DataSource.
Таким образом соединение с базой прописывается один раз и навсегда внутри сервера приложений. И само приложение менять не нужно только для того чтобы поменять настройки к базе.

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

Как вариант - дефолтные настройки всё так же живут в коде и читаются через Class.getResourceAsStream(). При первом старте сервер их копирует в user.home или java.io.tmpdir. Там админ их может менять. А сервер их будет перезаписывать поверх дефолтных. Соответственно Админу не нужно менять сам сервер.

И последнее - структура вашего проекта в некой IDE абсолютно не важна. Важно то как ваше приложение собирается в JEE модуль (war) и потом деплоится на сервер. IDE скрывает от вас этот процесс и это приводит к недопониманию. Соответсвенно для начала соберите war и задеплойте его в Tomcat самостоятельно. А когда разберетесь с процессом, то используейте IDE для тестового деплоймента.