Deserialization for remoting shouldn't require class on classpath

[julian-zucker]

Describe the bug
Currently, you have to build Evvo with the classes you'll be using in your Islands before you can deploy the RemoteActorSystem. This makes debugging take longer, as you have to re-build/deploy your servers anytime you change your local functions.

To Reproduce
Run any cluster, add a new Creator/Modifier/Deletor/Objective, try and launch a remote island.

Expected behavior
It should "just work". Regardless of whether the source files were there on the classpath during compile/docker build time.

Screenshots''

Additional context
https://docs.oracle.com/javaee/7/api/javax/jms/ObjectMessage.html
I've been doing my research, and I've read that JMS ObjectMessages can deserialize an object without having the class on the classpath. This is worth looking into.

[drassaby]

So I've been thinking more about this. I think we can (at least for now) call this a security feature instead of a bug. If one server is compromised, code that the user didn't write can't be executed on other remote servers. @julian-zucker what do you think?

[julian-zucker]

You can call it a security feature if you want, because it does make the code more secure.

This is still required for having an Evvo cluster exist independently of a problem/be re-usable for multiple problem types. Maybe it's not an issue for now, when we're just using it for one-time workloads, but if you want to productionize Evvo it would have to accept multiple problems, otherwise you will have to spin up a new cluster for each workload.

[julian-zucker]

Looks like this is the right idea:
https://stackoverflow.com/questions/1010919/adding-files-to-java-classpath-at-runtime

We could create a new Akka message that contains the bytes of a .jar file, send those messages to the worker nodes, write those bytes to a file, and pass the filepath to a dynamic url loader, like

URLClassLoader urlClassLoader = (URLClassLoader) ClassLoader.getSystemClassLoader();
DynamicURLClassLoader dynalLoader = new DynamicURLClassLoader(urlClassLoader);

Where a `DynamicURLClassLoader` is defined as a Scala-ization of

public class DynamicURLClassLoader extends URLClassLoader {

public DynamicURLClassLoader(URLClassLoader classLoader) {
    super(classLoader.getURLs());
}

@Override
public void addURL(URL url) {
    super.addURL(url);
}

}

This class may seem silly, because it just calls super, but `addUrl` is protected on the parent class, and exposed here. So, there is a real reason to write this class.