Greetings!
Shouldnt you get away with not changing the discovery.type to "single-node" for your single-node case?
Using the cluster discovery.type with the discovery.seed_hosts and cluster.initial_master_nodes only containing your single node should suffice to bootstrap the "cluster".
Without having tested it the doc´s make it seem so:
It is technically sufficient to set
cluster.initial_master_nodeson a single master-eligible node in the cluster, and only to mention that single node in the setting’s value, but this provides no fault tolerance before the cluster has fully formed
The cluster will boostrap and start it seems, obviously the multi node resilience is missing until "the cluster is fully formed" but thats to be expected with a single node. But to be able to not provide fault tolerance the "cluster" has to be running in the first place, before having formed/connected with other nodes 
Which makes me think it works.
discovery.type
Specifies whether Elasticsearch should form a multiple-node cluster. By default, Elasticsearch discovers other nodes when forming a cluster and allows other nodes to join the cluster later. Ifdiscovery.typeis set tosingle-node, Elasticsearch forms a single-node cluster and suppresses the timeouts set bycluster.publish.timeoutandcluster.join.timeout. For more information about when you might use this setting, see Single-node discovery.
The discovery.type doc makes it seem like you will receive timeouts in this single node dispite cluster formation case but that should be just about it.
After the "cluster.publish.timeout" happened on the single node, the cluster should start is my guess.
Depending on your deployment process you could also overwrite the settings of the elasticsearch.yml (and all other config files in the ELK realm) on startup by adding command line parameters to their execution.