[Messages] Improve throughput of jobs

[odesenfans]

Several improvements to the pending TX/message jobs.

• The jobs used to work by batch, meaning they started a series
  of N tasks and then waited for these tasks to finish before
  starting the next batch. This has the obvious disadvantage
  that the job ends up waiting on the slower tasks, while other
  tasks could have been started earlier. The jobs now have a
  max concurrency parameter that limits the total number of tasks.
  The job will automatically collect any finished task and spawn
  new ones up until the limit.

• Refactored the message processing job to get rid of the i/j
  logic that modified the batch size depending on whether the job
  was processing STORE messages. The job now uses a system of
  semaphores per message type that can limit the number of tasks
  running in parallel for a specific message type. This is still
  suboptimal as using semaphores per item type would make more
  (to limit the number of tasks fetching data from the network
  or ipfs), but this feature will be implemented later.

• Several job metrics were removed, as they lost meaning:

  • pyaleph_processing_pending_messages_gtasks_total
  • pyaleph_processing_pending_messages_i_total
  • pyaleph_processing_pending_messages_j_total

  These metrics were replaced by:

  • pyaleph_processing_pending_messages_aggregate_tasks
  • pyaleph_processing_pending_messages_forget_tasks
  • pyaleph_processing_pending_messages_post_tasks
  • pyaleph_processing_pending_messages_program_tasks
  • pyaleph_processing_pending_messages_store_tasks.

• The max concurrency parameter of each job and the limits per
  message type can now be configured from the config file.