reword documentation on nix-store --import

[fricklerhandwerk]

• add links to definitions of terms
• one sentence per line
• be more specific about which store is used for the import
• clearly distinguish store paths and store objects
• make a recommendation to use nix-copy-closure for efficient SSH transfers

Motivation

reworking documentation around use cases related to nix-copy-closure, as discussed with @eflanagan0

Context

related: #10708

Priorities and Process

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[edolstra]

It's probably a good idea to add a warning that nix-store --import / --export is deprecated since it doesn't copy some necessary metadata (like the CA field).

[fricklerhandwerk]

Is the CA field necessary outside of the experimental feature? Because if not, that would be a bug in CA xor one could say that support for nix-store --export / --import is not in scope for CA. Deprecating would be odd given there is no stable replacement with feature parity.

Are there any other metadata from stable functionality that are not preserved?

[edolstra]

Yes, the CA field is stable and not directly related to ca-derivations.

See also #9474 (comment).

[fricklerhandwerk]

TBH I'm don't know in what way the command is broken, what the CA fields are for, and what happens if they are missing. I'd be glad to document that if you can point me to the relevant test cases or code. But the straightforward example in this PR works - is there any reason not to merge that?

[Ericson2314]

@fricklerhandwerk the details of the CA field I don't think matter for this. What is going on is:

1. The import/export format lacks versioning
2. The (stable features only even) metadata has changed since import/export was created
3. import/export is thus lacking functionality in a number of hard-to-describe ways.

Exhaustively figuring out all the missing functionality would be hard, but we can say something like

These commands are deprecated because they use an protocol that cannot be versioned/modified. As such, they transmit/receive via an obsolete encoding the store object metadata, causing store object written on the destination side to potentially differ from their counterparts on the source side in subtle ways. Please instead use... which does not have this deficiency.