Incorrect CORS variable definition in docker.env

[zackkrida]

Description

A user has reported an issue with our docker/es/env.docker file:

a issue i got after that was regarding
http.cors.allow-origin="/./"
in docker.env
it wasn't expecting "-" as valid string i have to change it to
http_cors_allow_origin=/./="/.*/"
then it was working fine

Note that this user is using WSL which could potentially be related. Otherwise it would seem that multiple of the values in our Elasticsearch docker.env file are invalid:

openverse/docker/es/env.docker

Lines 1 to 14 in 9525973

	# Disable XPack
	# https://www.elastic.co/guide/en/elasticsearch/reference/5.3/docker.html#_security_note
	xpack.security.enabled="false"
	discovery.type="single-node"
	http.cors.enabled="true"
	http.cors.allow-origin="/.*/"
	# Elasticsearch will reserve 50-60% of available system memory
	# if left to its own devices. Setting this to half a GB is sufficient
	# for local testing and prevent ES from hogging such a significant
	# amount of system memory.
	ES_JAVA_OPTS="-Xms512m -Xmx512m"

[dryruffian]

error: Recipe `dc` failed on line 212 with exit code 15
env COMPOSE_PROFILES="api" docker compose -f docker-compose.yml up -d
failed to read /home/adtiya/OpenSource/openverse/docker/es/env.docker: line 8: unexpected character "-" in variable name "http.cors.allow-origin=\"/.*/\""

this is the error message popping up

[sarayourfriend]

This is a docker compose bug, which should be fixed by upgrading to the latest compose once it comes out: docker/compose#12123

I'm seeing this locally now after running ov init (not on WSL).

We can either:
0. Versionlock Docker compose to the version before this bug (flaky long-term)

1. Convert this env.docker file to a real Elasticsearch configuration file
2. Update all the environment variables to use Elasticsearch's actual environment variable rules, which are listed here: https://www.elastic.co/guide/en/elasticsearch/reference/current/docker.html#docker-configuration-methods

The last option is the easiest, but ultimately hurts discoverability of what those options mean (much harder to search ES docs or the web), so I'd only consider it a stop-gap to using a regular Elasticsearch configuration file.