Incorrect error handling with Perforce can lead to missing changeset in FishEye repository data

Actual behaviour

Currently when any perforce related error happens when FishEye tries to get p4 describe -dn for a batch of changesets, it fallbacks and tries to get the data for changesets one-by-one. If this fail, FishEye will try to call p4 describe -s and if this will fail again FishEye will ignore given changeset as it wouldn't exist in a repository. This will lead to missing changesets information and FishEye repository model won't represent actual repository structure. 

FishEye will log the following message to log files:

Removing changelist 321

However, the bug can present itself long after the log file rotates and log message is already gone. This lead to hardly reproducible problems which are nightmare to find the root cause. Missing changeset information can have an impact on whole FishEye&Crucible products, e.g. file ancestries, commit graphs, diff generation.

Expected behaviour 

FishEye correctly handles which come from Perforce, correctly fallbacks from batch mode and does not loose any changeset information. In case of persistent errors, propagate the exception into upper callee levels.