What would I expect from a sane program (a shell script or not):

• I never ever have to alter the executable to just configure it. This is not an OS kernel.
• I can pass any setting using command line. This is a must for every piece of information that does not have a reasonable default. The only exception is a password which needs interactive input.
• Optionally, I can pass a setting using an environment variable.
• I can write the settings down into a config file, and this file will be used if it is present under a well-known name, or explicitly pointed to using the two methods above.
• The config file uses the very same setting names and syntax as command line.

There are three principally different approaches:

1. Have the applications pull the configuration every time.
2. Have a tool to push the configuration to the applications when it changes.
3. Make sure the configuration does not change.

In increasing order of preference. So

3. Make sure configuration does not change.

This is the preferred option. Create suitable aliases for everything that don't need to change.

Domain name for mail server should never change. The host can, but you just redirect the mail.company.com or mail.inranet¹ to the new host. The same applies for all other network locations. Just create suitable DNS names for them. The same goes for database.company.com, ldap.company.com, self-service.company.com etc. Each web service and web application should have it's own vhost too, so you can move each independently without having to change the dependent applications.

The only case where the host names would change is when when you for example split the database server to two separate databases, but then you have to configure different applications differently, so the central configuration isn't going to help you anyway.

Similarly, each application should have separate account to the database, named as the application and limited to only the operations the application needs. This is for security reasons to minimize the damage if some of the applications is compromised. As a side-effect, it gives each application it's own username and password that don't need to change often, so no more reason for central configuration. Quite contrary; you want to limit the number of places that have each password so when somebody cracks one, the other applications and their accounts are not compromised.

In a sense, it is a shared configuration, but stored in the DNS server. And don't forget DNS can store various other information. There is the SRV record for recording ports where services run, records for storing various kind of encryption keys etc.

2. Have a tool to push the configuration to the applications

There is various configuration management software. These are tools that take care of installing software and deploying configuration across networks. Any non-trivial network should use one to ensure installing security updates.

If you have one, just add appropriate rules to deploy the properties file to all servers that run some application. If you don't, pick one² and do the same, plus configure it to take care of the security updates.

Note, that these tools can also take care of restarting the application servers when they deploy new configuration or otherwise notify the applications that they need to reload the configuration.

So this is a good option, because such tool is very useful for administering the network in general.

3. Have the applications to pull the configuration.

This requires changing each application in advance. And it won't solve the issue completely anyway, because it suffers the chicken-and-egg problem. You still have to configure the location from which you should pull the rest of the configuration.

File sharing is obviously easiest regarding size of changes to each application. Just remember you'll have to restart the applications too or implement some mechanism for notifying them when configuration is changed, which also reduces the usefulness of the solution.

So I would definitely not recommend this approach of which all your original options are variations.

¹_{You can use arbitrary non-existent top level domain in internal network and it has the advantage that you won't have to change it even if the company is renamed. Just don't use .local, which is reserved for mDNS.}

²_{Or ask your system administrator to pick one; they are the one who will interact the most with it.}