Serve install script (only) from Dream server

[Leonidas-from-XIV]

This PR moves the install script from the get.dune.build server to the script served by nightly.dune.build.

The previous setup used to copy the install script to get.dune.build as part of the daily sync action, but this has some distinct disadvantages

1. Once a change to the install script is merged, it takes for the sync action to run until the new version is deployed. This two step process is tricky because it is easy to forget to run the action and then the script will only be updated on the next run (which might only happen after a few days if no changes to dune occur). This means that it can take multiple days until a change happens and things can be broken for a longer time (e.g. change over the weekend)
2. It's rather complicated to understand. It is fairly understandable that get.dune.build is used to host the binaries, but the fact that the install script is served by both the binary-distribution Dream app (which serves the most currently deployed main version) as well as get.dune.build (the latest version from the github action) is confusing. This simplifies the code base to always just use one of them.

[shonfeder]

If everything is working now, could we hold off on any more updates that may impact service or correctness for the time being?

[Leonidas-from-XIV]

I don't understand your comment. Should we then basically archive this repository?

This PR is my suggestion on how to prevent accidents like #178, where I did not understand why there were two install scripts and just switched the URL without realizing that it would also change all the artifact links. This reduces the amount of install scripts to one and splits out the artifacts URL into a separate variable.

I think dealing with it now is a good idea, as the way it works is fresh in our minds. If we come back to this repo at a later point in time like in like half a year, or someone else will take a look at it, they might struggle with the same issues and potentially cause the same bugs.

[shonfeder]

Let's hold off on this until

• After the arc of the MSP work is done.
• We have a documented and effective strategy for testing these kinds of changes to ensure they don't break the existing service.

[maiste]

For the sake of information, this was decided when there wasn't the question of having a website to serve the "preview". Hence, everything was stored on get.dune.build. With this PR change, this is definitely better for the maintainability of the project 😄 With the rebranding, I'm wondering if the get.dune.build shouldn't be removed completely: I find it a bit confusing to have both names, now it is clear this is providing nightly versions of Dune.

Also, small review but if you change that, you can remove this part from the end of the README:

One downside of this setup is that the install script on
`nightly.dune.build/install` is updated as soon as the `main` branch is
deployed, however the install script at `get.dune.build/insall` is only updated
once the `binaries` action is run. Which can take several days if no changes
are happening in the Dune repository.

[Leonidas-from-XIV]

While I still think that we shouldn't serve the install script from two locations I've come around to the idea that the better place to serve the script from is the static server, as this gives us better scalability and caching opportunities. So I am closing this in favor of an approach like #229 where the data is basically all static.