Speed up BOMR library resolution

[mhalbritter]

BOMR takes a lot of time to look for library updates. Looking for a single version can take up to 17 seconds in my tests. This can be sped up by using multithreaded lookups.

While we're at it, we could improve another thing: right now, BOMR looks for update, and if it finds one, it waits for user input if this update should be applied before continuing looking. This can be improved by first collect all available updates, and then prompt the user. The first phase takes longer but the user can then do something else, and when the long phase is done, the user is asked for all the update choices without further waiting time in between the choices.

[mhalbritter]

BOMR library update search now uses 8 threads by default. Running gradle with --info now shows which library search took how much time.

See the commit message of e0b7720 for further details

[wilkinsona]

Unfortunately, I think we should revert this. Using multiple threads to resolve the versions in the way that we do is pushing the limits a bit for what's acceptable client behavior. I learnt this the hard way in the early days of Bomr when I managed to get my IP address blocked due to making too many requests that looked like a scraping tool.

I do like the idea of speeding this up though. I wonder if we could use the Maven Central Search REST API instead. The search index lags Central itself a little so we may miss some very recent releases but the benefits may well outweigh that.

[mhalbritter]

Oh noes :/ I agree that 8 threads may be too much, but what about 2 threads? This way if one thread blocks a long time, the other can still resolve.

I'll take a look at the Search REST API.