Navigate to correct stats page for Jetpack sites using XML-RPC API

We currently have the following logic for when the stats button is tapped on the MySiteFragment:

SiteModel selectedSite = getSelectedSite();
if (selectedSite != null) {
    if (!mAccountStore.hasAccessToken() && selectedSite.isJetpackConnected()) {
        // If the user is not connected to WordPress.com, ask him to connect first.
        startWPComLoginForJetpackStats();
    } else if (selectedSite.isWPCom() || (selectedSite.isJetpackInstalled() && selectedSite
            .isJetpackConnected())) {
        ActivityLauncher.viewBlogStats(getActivity(), selectedSite);
    } else {
        ActivityLauncher.viewConnectJetpackForStats(getActivity(), selectedSite);
    }
}

I don't think that's entirely correct because it doesn't check which API a site is using. For example, I have a site that's connected to Jetpack on my main account. If I login to the app with my other account and add my Jetpack site as self-hosted site, tapping on the Stats button shows the actual Stats page and telling me that it couldn't be refreshed at this point.

I don't know what exactly we want to see happen, but I think we should be utilizing selectedSite.isUsingWpComRestApi() to check the API the site is using to make better informed decisions. If I am not missing anything, here are some different scenarios we might want to handle separately:

1. WordPress.com site
2. Self-hosted site with Jetpack uninstalled
3. Self-hosted site with Jetpack installed, but not connected to any account
4. Jetpack site connected to the logged in account
5. Jetpack site, but the user is not logged into WordPress.com in the app (added as a self-hosted site and using xml-rpc api)
6. Jetpack site, but the user is logged into a different WordPress.com (added as a self-hosted site and using xml-rpc api)

I believe we currently convert self-hosted sites to Jetpack sites when the user logs in and the information matches, but I might be wrong about that. If it's possible to have duplicate sites, one added as self-hosted and one added as Jetpack site, I think we should fix that first because that'd make it much harder to handle this issue.

@aerych Since NDE is working on Stats refresh, would this be something that NDE could look into? If not, I am happy to work on this, but I'd still need help deciding what exactly we want to see happen in each of these cases, could NDE help with that?

P.S: I am not adding Stats Refresh label to this, because it's just Stats related unless it's done as part of that project.

Start in MySiteFragment, where the stats-button decision logic calls ActivityLauncher and checks the selected site's Jetpack and WordPress.com state. Review selectedSite.isUsingWpComRestApi() against the six listed site and account scenarios, first establishing the expected destination or connection flow for each. Done means each scenario reaches the correct stats or setup page without the failed refresh state.