Read canister ID from canister

[nmattia]

This includes a few changes that together make the frontend read the canister ID from the canister. This means:

• The same wasm module can be used anywhere (since the canister ID isn't baked in anymore)
• The webpack config is a lot saner and doesn't rely on assumptions and hard coded values
• You can now npm run build without having to first start the replica + call dfx canister create (or after having wiped .dfx/).

This includes the following changed:

• The <script> tag in index.html is now a dummy; the real content is injected in the backend. The real content includes the canister ID. Notes:
  • By doing this -- as opposed to e.g. fetching a config file also served by the canister -- we don't need to deal with promises and the FE code doesn't need to change
  • This means the SRI hash (for CSP) is now dynamic, so we compute it on startup (init/post_upgrade)
• Iterating over the assets (to insert the hashes in the certification map/tree) isn't callback-based anymore; instead all assets have a static lifetime. This also ensures that assets are created once and (in the case of index.html) aren't duplicated.
• The webpack config changed a bit. In order to retain the live reload feature (when using npm run start) we make sure that only the index.html is fetched from the backend; that way, the index.js is still local. The webpack config doesn't assume that the canister has been deployed anymore; now it only tried reading canister IDs when the server is started; before, it would do so at build time as well, meaning you couldn't build the FE if your canister hadn't been deployed (ok, created). I think this is much, much saner.

[bitdivine]

How has this code been tested?

[nmattia]

How has this code been tested?

• @bitdivine

This has been tested manually locally and automatically by selenium and the backend-tests on CI. This will also allow us to test the wasm on mainnet with a different canister ID than the official II.