Add remotes.json auto updation script

[shiv-tyagi]

Should be merged after #79

This script automatically creates/updates the remotes.json file to be consumed by the custom build server, listing the versions allowed to be built. It scrapes firmware.ardupilot.org and the listed subdirectories, determining releases and their githash using the artifacts. Then, it creates an object with metadata and adds it to the list of remotes in remotes.json.
If the remotes.json file doesn't exist or there's an error parsing it, a new file is created, replacing the existing remotes.json. If the file already exists, entries for other remotes are preserved, overwriting only the entry for the remote named 'ardupilot'.

To maintain static entries for the remote 'ardupilot' (which cannot be overwritten by this script), we can add a remote entry with a different name (e.g., 'ap-static'), using the same URL for the 'ardupilot' remote: https://github.com/ardupilot/ardupilot.git.

A sample remotes.json file would resemble:

[
  {
    "name": "ap-static",
    "url": "https://github.com/ardupilot/ardupilot.git",
    "vehicles": [
      {
        "name": "Copter",
        "releases": [
          {
            "release_type": "latest",
            "version_number": "4.6.0",
            "ap_build_atrifacts_url": "https://firmware.ardupilot.org/Copter/latest",
            "commit_reference": "master"
          }
        ]
      }
    ]
  },
  {
    "name": "shiv-tyagi",
    "url": "https://github.com/shiv-tyagi/ardupilot.git",
    "vehicles": [
      {
        "name": "Copter",
        "releases": [
          {
            "release_type": "latest",
            "version_number": "Custom",
            "commit_reference": "master"
          }
        ]
      }
    ]
  },
  {
    "name": "ardupilot",
    "url": "https://github.com/ardupilot/ardupilot.git",
    "vehicles": [
      {
        "name": "Copter",
        "releases": [
          {
            "release_type": "latest",
            "version_number": "4.6.0",
            "ap_build_atrifacts_url": "https://firmware.ardupilot.org/Copter/latest",
            "commit_reference": "202cc6ae9d326a172be5ec1120d79595a6ddae36"
          },
          {
            "release_type": "stable",
            "version_number": "4.3.0",
            "ap_build_atrifacts_url": "https://firmware.ardupilot.org/Copter/stable-4.3.0",
            "commit_reference": "93448b71380c417644c9082b7b23e80fb982b626"
          }
        ]
      }
    ]
  }
]

In this file, the fetch_releases.py script would update only the metadata under the object for the remote named 'ardupilot'. This model allows for dynamically updating the list of releases at custom.ardupilot.org, listing branches/tags for builds that are not standard releases, and allowing builds from different remotes.

Update:- We now do this using git tags after @peterbarker's suggestion. Also, we can securely trigger a refresh on the application by sending a POST request at /refresh_remotes endpoint after updating the file. The POST request should contain a token named CBS_REMOTES_RELOAD_TOKEN which is retrieved from the environment. This is used to make sure that any unauthorised user cannot trigger a refresh by hitting the above mentioned endpoint.

[peterbarker]

I'm still not sure why we're not looking at the ArduPilot source tree to get this information - and adding bits and pieces on top of it.

[shiv-tyagi]

Thanks for the suggestion @peterbarker. I have changed the approach. Please review and feel free to merge if it looks good to you.