Add support for Rollout on list of big list (100k+) of controller ids

[avgustinmm]

Sometimes, the set of targets to update may be a list of targets from different management systems - in that case, the standard RSQL filters don't work since controllerid =in= (....) could become too big (over the target filter restriction of 1024 characters).
To implement this we could add support for special case controllerid =in= (....) and bigger rsql query passed to create rollout:

• if rsql size <= 1024 - normal roollout - nothing to change
• else

  • if dynamic -> error (only static support controllers list shall be supported, tagging - see below)

  • else ( size >= 1024 & static rollout):

    filter: (contrillerid =in= (set_0) and type == 1 or conrollerid =in= (set_1)) and controllerid =out= (set_2)

    1. create unique - UUID (16 chars, or whatever), e.g. e.g. $ro_<tiemstamp>_<rnd>
    2. replace filter with: (tag != (<unique>_0) and type == 1 or tag == <unique>_1) and tag != <unique>_2
    3. check if the new filter size is <= 1024, if not - error
    4. store /<tenant>/<unique>_0, /<tenant>/<unique>_1, /<tenant>/<unique>_2 as files
    5. create tags <unique>_0, <unique>_1, <unique>_2
    6. create rollout with the new filter - return success

    when rollout executor process CREATING:

    1. tag /<tenant>/<unique>_i targets with tag <unique>_i, when ready - delete file -> a marker that tagging is applied, could have (somewhere) marker for process
    2. if all tags are processed - proceed as for standard rollout - apply the filter

    when rollout executor process READY or DELETING

    1. remove tag - unique could contain some special format, as $ro_<tiemstamp>_<rnd>

Note: the file storage should be pluggable as artifact repository
(?) if tag is removed on _READY database will be cleaner but will lose some traceability - why does the rollout contain what it contains ...