feat(sql): Optimize executions

[kirangodishala]

This PR improves performance when using sql as the backend by optimizing the way the results are obtained for the api call /applications/{application}/pipelines?expand=false&limit=2 frequently initiated by deck.

Deck makes that call to Gate. Gate further forwards that call to Orca, specifically to /v2/applications/{application}/pipelines endpoint.

Orca calls front50 to get the pipeline and strategy config ids and then merges them. Then for each id in the merged list, it queries its own db (SQL) to handle the query parameters, such as limit=2 and filter by statuses. It is observed that these db operations are taking longer times and this PR fixes the slowness by optimizing the queries to the db.

Refactored TaskController to support externalized config properties

Optimize getPipelinesForApplication() by reducing the number of relevant pipeline config ids to query

Further optimize getPipelinesForApplication() by processing multiple pipeline config ids at a time and multi-threading each config id batch

Breaking changes:

These configuration properties

tasks:
   days-of-execution-history:  
   number-of-old-pipeline-executions-to-include: 

are replaced by the below configuration along with few more newly added ones:

tasks:
   controller:
      days-of-execution-history: 
      number-of-old-pipeline-executions-to-include: 

      optimize-execution-retrieval: <boolean>
      max-execution-retrieval-threads:
      max-number-of-pipeline-executions-to-process: 
      execution-retrieval-timeout-seconds: 

[jasonmcintosh]

MINOR: BUT ... this ordering DOES matter on the selection criteria and don't think we have a test for this (aka primary MUST come first or it'd select previous data potentially). Just an observation that this is missing a test .. but not sure how "critical" that test really is.

[jasonmcintosh]

Question: DO we really want to force an index, or is another index on the combination needed? OR perhaps merging a couple of these indexes. NOT sure best solution but... we have a number of indexes with some of this data and wondering if we couldn't do this a touch cleaner. I'd EXPECT the optimizer to handle MOST of this without the need to force an index.

[christosarvanitis]

The whole idea seems like a good optimisation to me 👍 @dbyron-sf @kirangodishala how long have you been running this in your forks?

Also could we fit the same concept of optimisations in retrievePipelinesForPipelineConfigIdsBetweenBuildTimeBoundary in this PR?

[jasonmcintosh]

There.. are long term things I'd like to evaluate - primarily DB indexes & see if we can move some of this logic out of code or simplify it in some way, but... this is a good start on improving the response times. I worry a touch in a COUPLE spots on how it handles things around in-memory/threads, but for now, approved.