Feature request - Extend packs pack functions

I would like to extend the packs pack and the backing code under st2common

Thinking of splitting out the git code into its own py file (class) to make way for non git based installs (http(s), s3 buckets, etc), I want to make it easier for folks to write in new download code. Also looking to support more than directories for my use case which is to pull a tar file from either s3 bucket or http by changing requests to the packs pack.

To do this the pack.download could either take an extra input to allow you to specify the client you wish to use with the default being the original git class.

Another option might be download clients could have a class property representing priority and another property representing rules that could be used to match whether the class could be used to complete the download. This would allow the consumer to provide a url like file:// git@ github@ the way they do now and use the original download method or s3:// to use a s3 bucket and so on.

In addition to above looking add an override option in st2.conf to allow users to specify packs they wish to bypass the USER_PACK_NAME_BLACKLIST check allowing them to call on the packs, I'm not sure if this is necessary as it currently hasn't blocked me but I thought for completeness this should be in, though this might be best being raised in a separate feature.

Just an idea

Start by locating the packs pack's pack.download implementation and the backing code under st2common, then review how the existing Git download path works. Read the st2.conf handling and USER_PACK_NAME_BLACKLIST references for the proposed override. Done would require an agreed design and implementation for extensible download clients, additional source types, and any approved blacklist override.