If HTTP is the only API your Go application exposes, then you're only left with the option to just send a HTTP request to Go. Yes you can start the Go executable as a child process from the JVM using a
ProcessBuilder. But that's not truly embedding go within your WAR. You can use JNI (Go bindings are called GoJVM) to invoke native routines in Go from Java, but then you have to make a lot of adjustments to your Go code base as well.
What you are looking probably for is indeed a reverse proxy. It's not frequently done in servlets / application servers, because this is usually done in load balancers already. So usually that would be NGINX or httpd with
mod_rewrite. For application servers, you can use a proxy servlet.
The memory footprint is usually not to bad, because you're essentially only connecting the streams. The JVM will be able to track processor and memory utilisation - if implemented properly and the Go executable runs on the same server. Obviously the Java specific statistics don't make much sense anymore, as you're only using your Java server as a pass-through.
Sounds like you will be in trouble though. If my strict requirement was a WAR-archive that can be deployed to an application server, I wouldn't accept another executable added to my stack. Reverse proxied or not.