Remote backup location ID getting reset

[GentlemanHal]

Bug report

Nevergreen version?
v7.0.0+3503.814c359 Razzmatazz

What are you running on?
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36

Expected behaviour?
The ID should not get reset when importing.

Actual behaviour?
The ID gets reset when importing.

Steps to reproduce?

1. Add remote location
2. Select GitHub gist
3. Don't enter an ID (which will create a new gist)
4. Add location
5. Export to the location
6. This will set the ID
7. Import from the location
8. The ID will be reset back to blank

This is happening because the ID for new gists is only getting created after we export for the first time, as this is the action that creates the gist. This means that the configuration that is actually saved in the gist doesn't have an ID.

The ID is returned in the response from the first export and set in the local state. This is why importing from the gist without exporting to it again results in the ID getting reset to blank, as that is the ID saved in the gist.

This is likely to be a problem for GitLab snippets as well.

Possible fixes 🤔

Some potential ideas to fix, in no particular order!

• Create new gists/snippets when adding the location so we always have an ID
  • The gist/snippet would just be empty until the user exported for the first time
• Decouple creating the gist/snippet from uploading the configuration when exporting
  • Similar to the above option, but only done when the user triggers an export rather than on adding
• If we are exporting to a new gist/snippet we could trigger another export to make sure the saved configuration contains the ID
• Stop overwriting IDs when merging imported configuration in the reducer
  • This would be OK now, but might cause some issues once #339 is implemented