WASM actor upload system

[PabloMansanet]

At the moment, the number of live players is equal to the number of valid .wasm player files under crates/bomber_game/assets/players. For the meetup, we want a system that makes it easy for attendees to upload their compiled players and see them reflected on the game field immediately.

How it would be used

• It would be amazing if we could make it part of build.rs so an attendee only needs to run cargo build on their player crate and have the build script pick up the output and stream it to the right port. Unfortunately build.rs can do pre-build steps but not really post-build steps as far as I know, so the only ways I can think of making this happen would be a bit hacky.
• An alternative could be to come up with a custom cargo command, so that attendees can call cargo upload-player, which will in turn build the crate for the wasm target and upload the resulting .wasm file in one go.

Server side

• An option could be to have a bevy system (using one of the network plugins) just picking up connections to a TCP socket and streaming the bytes directly into .wasm files. This would then be picked up by the folder watcher, and we'd have a way to mix uploaded players and players we manually "drag and drop" into the server.
• Alternatively we could get rid of the folder watching altogether, and have it so the networked bevy system directly builds the wasm asset from the TCP stream. This would be cleaner but lose the benefit of the "drag and drop" option.

Concerns

• Ideally attendees will have only one hero at any given time, so we have to come up with a robust way of identifying which .wasm upload belongs to which attendee. We could pin it to IP addresses, or request attendees to implement a player_name() method in the player trait so that we can decide at runtime whether they are a duplicate.

[strohel]

How it would be used

• another alternative could be that the main (or another) binary of the example actor crate would simply upload the produced WASM to the server. That could work as the WASM module is considered to be a "lib" target? Uploading and running updated actor could then be a matter of cargo run or cargo run --binary upload. Server side
• another option would be to keep the folder watching and just fire up some existing tool to serve as an "upload server". (I don't necessarily think this is a better idea).

[PabloMansanet]

• another alternative could be that the main (or another) binary of the example actor crate would simply upload the produced WASM to the server. That could work as the WASM module is considered to be a "lib" target? Uploading and running updated actor could then be a matter of cargo run or cargo run --binary upload.

I really like this idea, especially if we can get it to work with just cargo run. The only part I'm not sure about is target interactions; you probably can't do it in one go as you'd like to build for wasm but run for a native target, but at worst it's just two commands instead of one.

[bschwind]

A Makefile or script would probably be fine as well - make upload or ./run.sh

We could make one for Windows as well, though I see the appeal of having everything handled via just a cargo invocation.

[skywhale]

• Alternatively we could get rid of the folder watching altogether, and have it so the networked bevy system directly builds the wasm asset from the TCP stream. This would be cleaner but lose the benefit of the "drag and drop" option.

+1 to keeping the current folder watching mechanism. I would imagine during the game event, the organizers (us) actually wanting to update the bomber_game code and restart rounds several times e.g. tuning game balance, closing loop holes. In that case, it would be nice to be able to load all the previous actors without having to ask the attendees to upload again. The .wasm folder serves as a persistency layer.