Optional sharing link information for Provider

[FelixGail]

Related: https://github.com/BjoernPetersen/MusicBot/issues/99

[BjoernPetersen]

I think just providing static information won't do. Sometimes there's some individual dynamic procedure required (see the new Spotify sharing links). Doing static extractions (i.e. by using a regex) on the client-side would of course be preferable, so maybe we should handle the two cases differently. How about creating a ProviderInfo object including info about sharing links, like this:

{
  "id": "com.example.provider.Spotify",
  "sharing": [
     {
        // Used to find out if this extractor is applicable
        "matcher": {
             // we may also allow matchers on full sharing string, the URL path etc.
             "host": "open.spotify.com"
        },
        "extract": {
            "pathRegex": "<regexToExtractIdFromUrlPath>"
        }
    },
    {
        // Used to find out if this extractor is applicable
        "matcher": {
             // we may also allow matchers on full sharing string, the URL path etc.
             "host": "link.tospotify.com"
        },
        "extract": {
            // Prompts a call to /provider/com.example.provider.Spotify/extractor/linktospotify with sharing link payload
            "remote": "linktospotify"
        }
    }
  ]
}

Especially unsure about this one yet: Resolving the "link.tospotify.com" link will yield an intermediate result (an "open.spotify.com" link). Should the plugin fully resolve the link or return the intermediate result with a corresponding flag, so the client can repeat the process with other matchers until it's done. That would deduplicate extraction code and allow for some highly decoupled extractors on the server side. On the negative side, clients will potentially have to make multiple remote calls per shared link.

I also have another idea on what to include in the ProviderInfo object: whether it should show up in the in-app search (YouTube probably shouldn't).

[FelixGail]

Can you think of any cases in which decoupled extractors are necessary? If not, the additional logic needed in each client might outweigh the de-duplication.

A presentation issue to consider: Would you provide something in the likes of a /share endpoint that provides sharing information for all providers or add the information to the NamedPlugin object?

I also have another idea on what to include in the ProviderInfo object: whether it should show up in the in-app search (YouTube probably shouldn't).

I think this should be moved to a new issue as there is more to consider before making a decision. E.g.: Invisible providers won't be advertised. Is there a feasible way to counteract this. What about clients without access to the resource (mobile without youtube app). Removing the in-app search would exclude them from using the provider...