Im not sure why you think this is not suitable for you. As I see it, you use-case matches exactly with the idea behind external configuration files in general and the context.xml file in particular.
The context.xml is a file that can live within the war containing the configuration option, or is sits outside of the war file in the conf directory of the tomcat and configures the datasource from the outside.
Take this example here:
In this app i have a context.xml within the war file, that defines a HSQL DB:
Then, outside of the war file I create a docker container. Within this container, I want to change the datasource with another user password (and even another DMBS like Postgres in this case):
The outer context.xml will override the properties of the file within the war file.
This technique works exactly the same way with the app.properties files. See the docs.
The question if a tomcat with mutiple wars running simultaneously is pretty much orthogonal to the above. Let’s say it has a lot of downsides and some upsides. But in fact it is not super common anymore to put all wars in one tomcat. But this is up to you, how you want to handle it.
E.g. when you use something like the Uber-jar then this decision is already made for you because the tomcat sits inside the war / jar file.