Bug 5399

Alias access-control for PR server.

It's not only about restricting write-access to anonymous users, it's more complicated than that, because it's not clear what such user should do when his signature is different than what PR server has.

One way is to add another level in EXTENDPRAUTO, but using max(from-r/o-pr-server).your-local-AUTOPR value doesn't work, because your different local signature isn't always "newer" than what build server has (and you don't want to downgrade some packages on target device and cause e.g. unresolved .so dependencies).

Right now I'm exposing writable PR server to local users, which has its own pros and cons.

pros:
- it's safer to let local users to "bump" it because at least they pre-allocate some number from their signature, so I can be sure that official build server won't build exactly same .ipk with different signatures

cons:
- 1) if you change busybox.bb and it gets EXTENDPRAUTO bump .1 -> .2
  2) some other change in busybox.bb EXTENDPRAUTO bump .2 -> .3
  3) some local user reports that the change from 1) was incorrect and prepares his own solution which integrates change from 1) and fix EXTENDPRAUTO bump .3 -> .4
  4) maintainer reverts 1) but because of 2) gets new EXTENDPRAUTO bump .4 -> .5
  5) maintainer cherry-picks 3) gets old EXTENDPRAUTO value .4 created by local user in step 3), so the fix is never seen by packagemanager as upgrade from .5

Of course you can get EXTENDPRAUTO going backwards a bit easier if you just push something and then revert it without any other changes - but in this case you can be careful and e.g. manually bump PR or something to create new version, but in previous example you usually don't know that some local user already pre-allocated .4 with his local signature and your feed is just unlucky to match it exactly - it doesn't happen often, because usually there are other commits which change signatures more quickly.

Honestly I don't see how to use PR server from multiple builders with possibly different metadata and get 100% reliable binary feed from that.

My current work-around is to copy prserv.sqlite3 as build artifact for my feeds and encourage users to rather use it as one-time import, rather than using PR server directly (I was doing the same with bb_persist_data.sqlite3 for LOCALCOUNT numbers).