mbsync: Tolerate MusicBrainz recording ID changes

[pprkut]

mbsync uses the musicbrainz recording id to match local track information against a certain track in a musicbrainz release. However, there is no fallback matching defined, so once the recording id changes in musicbrainz the local track can no longer be synced unless the recording id is changed manually. But this behavior is also not very visible (I stumbled upon it by accident), so most users would not even be aware that the recording id is outdated.

[Freso]

On recording merges (which I would estimate are somewhat more common than other kinds of merges), looking up a merged MBID should return the "new" canonical MBID in the WS response, which would mean that beet should just update the metadata. The real trouble would be if a recording has somehow gotten deleted (this shouldn't happen, but it still does on occasion) - I don't know what would be the best way to handle this, apart from re-importing. Perhaps a notice to the user that the recording should be re-imported, or try to resolve it using track or release MBID?

[pprkut]

It's not just merge and delete which could cause this though. If a track points to a wrong recording, and this is fixed in musicbrainz by pointing to the correct recording, both recording are still present. Fetching information for the old recording id in this case does not help us at all in getting the new one, similar to the delete case.
It's a matter of what would be considered an adequate fallback value for the recording id. Maybe once we have release track ids (#406) those could be used as well. Otherwise one could argue that track number + disc number might be sufficient the re-identify the track? This would however break when both position and recording are both changed.

[sampsyo]

Track IDs as a fallback seem fine, I think. Track/disc position seem dicier—it would be a good goal to keep "guesswork" out of mbsync. If things change a lot, a re-import is probably the right solution.