borg2: Make `serve --rest` the default, move legacy support to a `--legacy` option

[PhrozenByte]

After the removal of the legacy RPC protocol with #9732 (with a few exceptions, see below), it might be worth considering making the REST protocol the default mode of borg2 serve.

At this point, client-side use of the legacy RPC protocol is limited to borg2 transfer --from-borg1, where it is only used to migrate an existing borg1 repo to borg2. On the server side, borg2 serve still supports serving a borg1 repo via the legacy RPC protocol so users do not need to keep a separate borg1 installation around during migration.

However, borg2 serve still defaults to the legacy RPC protocol and requires --rest to serve a borg2 repo via the new REST protocol. I suggest inverting this default: borg2 serve should serve a borg2 repo via the REST protocol by default. Serving a borg1 repo via the legacy RPC protocol should require an explicit option such as --legacy.

In general, legacy compatibility modes should require explicit opt-in, while the default behavior should reflect the current architecture.

The main downside is that existing SSH forced-command configurations would need to be adjusted. However, borg2 is already a breaking release, and the remaining legacy RPC support exists primarily to facilitate migration from borg1. Given that context, requiring an explicit compatibility flag for legacy operation seems reasonable.

Prior discussion: #9593 (comment)
Related: #9765

[ThomasWaldmann]

I thought about that, but as it is now (requiring --rest for new stuff), it does not need editing of legacy forced commands AND it also does not matter whether they are served by borg 1.x or borg2, because the forced command is the same for both.

[ThomasWaldmann]

Also, when not using a forced command, the current code invokes borg serve as it always did. So it can talk to a server-side borg 1.x "borg serve" or to a borg2 "borg serve".

If I changed that to borg serve --legacy, it would fail with server-side borg 1.x because that does not know this option.

[PhrozenByte]

Is the borg1 compatibility mode of borg2 serve intended primarily as a migration aid, or as a long-term interoperability feature?

If it is primarily meant for migration, then one could also argue that the default should reflect the post-migration world. Effectively, one is required to change the SSH forced command anyway; what changes is merely whether this happens before/during migration or afterwards. Depending on the individual migration workflow, one might use different means of access during migration (e.g. direct filesystem access or SFTP), in which case changing the default could eliminate the need for any ForceCommand changes entirely.

On the other hand, if serving borg1 clients from a borg2 server is intended as a long-term use case, then I can absolutely see why keeping the current default is attractive. Would it be technically feasible for borg2 serve to detect the desired protocol from the initial protocol exchange and select the mode automatically? This might eliminate the need for CLI options entirely.

There's also the question of future releases: If legacy RPC support is eventually removed entirely (I vaguely remember Borg 2.1 being mentioned as a possible point of legacy code removal in general?), would --rest then remain as a required but effectively redundant option, or would the defaults be revisited at that point?

If I changed that to borg serve --legacy, it would fail with server-side borg 1.x because that does not know this option.

That is a strong argument indeed.

Out of curiosity, assuming it isn't possible for borg2 serve to safely distinguish whether it's speaking to a borg1 or borg2 client, would the other way round be possible, i.e. for borg2 transfer --from-borg1 to safely distinguish between borg1 serve and borg2 serve, prompting a reconnect with borg2 serve --legacy?

[ThomasWaldmann]

It's a migration aid for borg 2.0 and I hope we can get rid of it (and all the other legacy) quickly, like in 2.1.

After that, borg serve --rest could also be the default, so it does not matter whether one gives --rest or not.

Yeah, maybe client/server could automatically detect it.