Redirect incorrect Android devbuild update URL

In ABP for Android 1.2, we've accidentally put all release users on the devbuild update channel. However, luckily, the URL is incorrect (it's the default one from libadblockplus), so we can safely redirect this to the real release channel - the real devbuild users are still on the real devbuild channel.

[Wladimir Palant, 2013-12-17 15:48:14]

This is actually the correct new update URL for the development builds. Rather
than redirect it we should disable it - maybe some development build users
didn't update yet. This should do:

location ... {
  internal;
}

[Felix Dahlke, 2013-12-17 15:55:05]

On 2013/12/17 15:48:14, Wladimir Palant wrote:
> This is actually the correct new update URL for the development builds. Rather
> than redirect it we should disable it - maybe some development build users
> didn't update yet. This should do:
> 
> location ... {
>   internal;
> }

Wouldn't we want to forward this to the new release URL then? (The same would go
for updates.xml on server_1, since it looks like 1.2 is checking both URLs)

[Wladimir Palant, 2013-12-17 15:57:48]

The format isn't the same, we will need to provide both URLs for a while.
Whoever isn't on the latest devbuild yet will be checking updates.xml only so if
we disable that URL they won't update - and we can enable the URL again once
we've migrated release users from the devbuild channel.

[Felix Dahlke, 2013-12-18 00:41:35]

On 2013/12/17 15:57:48, Wladimir Palant wrote:
> The format isn't the same, we will need to provide both URLs for a while.
> Whoever isn't on the latest devbuild yet will be checking updates.xml only so
if
> we disable that URL they won't update - and we can enable the URL again once
> we've migrated release users from the devbuild channel.

What I meant was that /devbuilds/adblockplusandroid/update.json should redirect
to /adblockplusandroid/update.json, instead of being disabled. The latter should
then be disabled for the time being, but I don't think we need to do anything
there, it already returns 404.

What I meant with "the same goes for updates.xml on server_1" was that we should
redirect the legacy devbuild update URL to the legacy release update URL as
well. Especially since that seems to be the only update method that actually
works.

[Felix Dahlke, 2014-02-27 18:07:28]

I didn't understand the actual problem when creating this issue. The new
devbuild update URL is being requested by ABP for Android 1.2, but the result is
ignored. Requests to the old update URL still happen in parallel, and those are
the ones actually used for updates.

The actual reason why all 1.2 users are on the devbuild now is that it considers
itself a devbuild, which is fixed here:
http://codereview.adblockplus.org/5094040492048384/

So I've changed this patch to redirect the old devbuild update URL to the old
release build update URL, which will promote all devbuilds into release builds
once we publish 1.2.1.

The next thing we should do is actually use the libadblockplus update mechanism
with the new URLs, I created a follow-up for that:
https://trello.com/b/8gOyWozv/adblock-plus-tasks

[Wladimir Palant, 2014-03-03 07:44:18]

http://codereview.adblockplus.org/5713977044631552/diff/5639274879778816/modu...
File modules/downloadserver/files/downloads.adblockplus.org (right):

http://codereview.adblockplus.org/5713977044631552/diff/5639274879778816/modu...
modules/downloadserver/files/downloads.adblockplus.org:36: rewrite ^
https://adblockplus.org/androidupdates.xml?$query_string redirect;
Won't the two update mechanisms be competing here? Meaning that it is pretty
much a question of luck whether one gets a development build or a release build.

[Felix Dahlke, 2014-03-03 09:18:19]

On 2014/03/03 07:44:18, Wladimir Palant wrote:
>
http://codereview.adblockplus.org/5713977044631552/diff/5639274879778816/modu...
> File http://modules/downloadserver/files/downloads.adblockplus.org (right):
> 
>
http://codereview.adblockplus.org/5713977044631552/diff/5639274879778816/modu...
> modules/downloadserver/files/downloads.adblockplus.org:36: rewrite ^
> https://adblockplus.org/androidupdates.xml?%24query_string redirect;
> Won't the two update mechanisms be competing here? Meaning that it is pretty
> much a question of luck whether one gets a development build or a release
build.

No, we don't really react to UpdateDownload events. So the app does the request
but nothing else happens.

[Wladimir Palant, 2014-03-03 15:11:21]

If you are right and the new update mechanism isn't hooked up at all (looks like
it): LGTM