Implement support for request priorities

[lucasr]

Not sure if you've considered something like this in the past but here it is. This patch implements request priority support in Picasso. This feature can be especially handy when you have UIs with lots of images and you want to have tighter control over which images should load first. This is inspired by Volley's API.

It adds a new API in RequestCreator to define the request priority:

Picasso.with(context)
       .load("http://example.com/image.jpg")
       .priority(HIGH)
       .into(someImageView);

Priority can be LOW, NORMAL, HIGH, or IMMEDIATE. BitmapHunters compute their priority in the executor by taking the highest priority of its attached requests. For example, if a BitmapHunter has two attached Actions, one LOW and and one HIGH priority, its priority will be HIGH.

[JakeWharton]

We have, but I think those might be too many priorities. This is the same problem as log levels. Everyone wants a lower log level or a higher log level because they abuse them.

I wanted only two, but I can probably be convinced for three. I don't think I can be convinced of four.

[JakeWharton]

incrementAndGet()?

[lucasr]

Done.

[lucasr]

@JakeWharton Fair enough. Let's start with just LOW, NORMAL, HIGH then. I think using only two priorities feels too "polarizing". Three gives enough flexibility for more complex cases.

[lucasr]

Updated branch:

• Update BitmapHunter priority when requests get attached/detached. getPriority() is now simple getter.
• Moar tests.
• Moar API docs.

[JakeWharton]

👍 👍 👍

One of the more challenging things I'd like to figure out is a way to limit the number of threads on which LOW priority requests can execute. Something like half the threads (and then rounded down). I'd like to be able to execute 100 fetch() requests, for example, but still allow NORMAL and HIGH requests to start without having to wait.

[felipecsl]

👍 well done @lucasr