By default, maps are loaded in HTTPS if WorkAdventure is running in HTTPS, and in HTTP is WorkAdventure is running in HTTP.
Also, if WorkAdventure is running in HTTP and map loading fails, we try map loading in HTTPS (useful when we are working on WorkAdventure locally and want to load a map on a secure domain).
This commit adds the last combination: If WorkAdventure is running in HTTPS, and map loading fails in HTTPS **AND** if the map URL is targetting "localhost", "*.localhost" or "127.0.0.1", then we attempt to load the resource in HTTP.
Why?
"localhost" is considered secure context by modern browsers. So even if a page is loaded in HTTPS, it can load resources from any secure context (including localhost in HTTP).
This means that from "https://play.workadventu.re", I can now test a map running locally on my machine (served by a classic webserver without any certificate).
This change should make map testing easier, since map developers will not have to install the whole WorkAdventure project to test their map locally.
In "alone" mode (or single-player mode), WorkAdventure does not connect to the server at all.
In order to enter the "alone" mode, you need to add "?alone=true" to the URL.
"alone" mode can be useful for tutorials (First Time User Experience) where you want to explain how WorkAdventure works without being disturbed by other users.
In a development environment, we often run in HTTP.
The problem is that WorkAdventure will attempt to load maps using the HTTP protocol (even if the map is on a remote server that is available only in HTTPS).
This commit adds a "fallback". If we are in HTTP (so in a development environment) and if the map fails to load correctly, we will try again, but in HTTPS.
This allows development environment to load maps hosted on a HTTPS enabled server easily.
This feature allows to add a "jitsiUrl" property in the map.
As a result, you can use for a given Jitsi room a custom instance of Jitsi.
Using "jitsiUrl" will only work with public Jitsi instances (authentication is not supported when "jitsiUrl" property is provided)
The Jitsi external_api.js script is now lazily loaded.
