Migrate full functionality of ipfs file ls to ipfs ls

[dokterbob]

Version/Platform/Processor information (from ipfs version --all):
0.4.3-rc3

Type (bug, feature, meta, test failure, question): question
Area (api, commands, daemon, fuse, etc): commands
Priority (from P0: functioning, to P4: operations on fire): P3

Description:
As explained in #3057 (comment), the ipfs file ls command is basically deprecated in favor of ipfs ls, awaiting the migration of some of its functionality.

What functionality is currently in ipfs file ls that needs to be moved and what will be the (rough) deprecation plan for ipfs file ls?

[dokterbob]

From looking at the code, the main difference seems to be that ipfs file ls lists the file size rather than the object size for File-objects whereas ipfs ls seems to always list the link size. This would mean that in integrating these, there are two ways to go:

1. Make the output of ipfs ls calculate sizes exactly like ipfs file ls, breaking backwards compatibility.
2. Create a command line option to display file sizes instead of link sizes, effectively optionally including ipfs file ls's functionality in ipfs ls.

Note, furthermore, that ipfs files ls also simply lists (cumulative) link size rather than unix file size, which is interesting given that this code seems meant, specifically, to match unix filesystem behaviour.

[dokterbob]

From #4580:
ipfs ls --enc=json gives back a number as the type (which I suppose, can be overcome).

Another difference, and this is a big point for us at ipfs-search.com, it does not tell us the type of the requested file:

{
  "Objects": [
    {
      "Hash": "/ipfs/QmYcutogfHrrxigzVw2Vi8P1cdiuXNn9VecL9cy95wB9MP",
      "Links": [
        {
          "Name": "reindex",
          "Hash": "Qmac74sj9SgTVVVHFgWrFL6wyUQ8k8sgK4LYcEPTNoz3jW",
          "Size": 18132,
          "Type": 1
        }
      ]
    }
  ]
}

ipfs --enc=json file ls /ipfs/QmYcutogfHrrxigzVw2Vi8P1cdiuXNn9VecL9cy95wB9MP

{
  "Arguments": {
    "/ipfs/QmYcutogfHrrxigzVw2Vi8P1cdiuXNn9VecL9cy95wB9MP": "QmYcutogfHrrxigzVw2Vi8P1cdiuXNn9VecL9cy95wB9MP"
  },
  "Objects": {
    "QmYcutogfHrrxigzVw2Vi8P1cdiuXNn9VecL9cy95wB9MP": {
      "Hash": "QmYcutogfHrrxigzVw2Vi8P1cdiuXNn9VecL9cy95wB9MP",
      "Size": 0,
      "Type": "Directory",
      "Links": [
        {
          "Name": "reindex",
          "Hash": "Qmac74sj9SgTVVVHFgWrFL6wyUQ8k8sgK4LYcEPTNoz3jW",
          "Size": 18132,
          "Type": "Directory"
        }
      ]
    }
  }
}

[dokterbob]

Note that ipfs files stat actually returns the type of the current file, so I think I would be comfortable removing ipfs file ls as soon as #5805 is closed.

However, there might be issues with listing particular kinds of directories, like HAMT, for which there might be interpretative conflicts between ipfs ls (listing linked nodes) and ipfs file ls (listing files). But perhaps the interpretation of ipfs ls is already files, as there is ipfs object ls for listing nodes already? Related: #3056

[jacobheun]

Closing this as we are tracking it in the #7493 meta issue