RF AnnexRepo: extend/unify init_remote and enable_remote

[yarikoptic]

datalad/distributed/tests/ria_utils.py already has

def initremote(repo, name, encryption=None, config=None):
    cfg = dict(config) if config else {}
    cfg['encryption'] = encryption if encryption else 'none'
    args = ['{}={}'.format(k, v) for k, v in cfg.items()]
    repo.init_remote(name, args)


def initexternalremote(repo, name, type, encryption=None, config=None):
    config = dict(
        config if config else {},
        type='external',
        externaltype=type,
    )
    return initremote(repo, name, encryption=encryption, config=config)

so IMHO we should just tune our existing init_remote and enable_remote to accept options given as a dict (and do above tune up), and init_remote get a kwargs encryption=None, external=False. That would simplify use of init_remote and remove custom (albeit generic) code in datalad/distributed/tests/ria_utils.py

[jwodder]

@yarikoptic So if init_remote() is passed external=True, what exactly should it do? I'm guessing you want the config dict to be augmented with the keys type and externaltype, but where does the value for externaltype come from? Should there also be a type (or externaltype) argument, or should non-False values for external be what's passed to externaltype?

[yarikoptic]

type is always needed AFAIK so yes - just add it as kwarg and then depending on either external or not it would be used as type or externaltype in the config dict to be passed (if list config was passed as it is implemented now and also any of type, encryption, externaltype -- raise ValueError("Specify options as `dict` .... `). Eventually we should just deprecate/remove list specification so may be right away issue a deprecation warning aiming for deprecation in 0.15?

[adswa]

I'm leaving a quick ping on this issue. As we discussed a few months ago in the internal chat, there are plans to reimplement ria-functionality in a dedicated extension, and thus I'm transferring issues with corresponding tags to that extension. When I found this issue, it felt like this is more about datalad core than ria, so I'll leave it here. However, I also noticed that the linked PR to this issue was only closed due to inactivity, not because of evident flaws. It could be worthwhile to recover it from https://github.com/datalad/datalad/pull/5065/files eventually.