Inconsistencies in displaying bucket and file metadata

[mpnowacki-reef]

As of now there are several inconsistencies when it comes to displaying:

• bucket default encyrption
• file retention

in

• b2 ls --json and b2 get-file-info
• b2 list-buckets --json, b2 get-bucket and b2 update-bucket

The inconsistencies are:

1. FILE INCONSISTENCIES

• b2 get-file-info displays raw data from server, therefore fileRetention and legalHold contain authorization data, and are of the form:

    "fileRetention": {
        "isClientAuthorizedToRead": true,
        "value": {
            "mode": null,
            "retainUntilTimestamp": null
        }
    },
    "legalHold": {
        "isClientAuthorizedToRead": true,
        "value": null
    }

or

    "fileRetention": {
        "isClientAuthorizedToRead": false,
        "value": null
    },
    "legalHold": {
        "isClientAuthorizedToRead": false,
        "value": null
    }

• b2 ls --json displays data by converting it to FileVersionInfo objects and then serialising it to dicts, therefore fileRetention and legalHold do not explicitly contain isClientAuthorizedToRead. Instead, information about permission to read can be inferred from the displayed value.

For an application key authorized to read these attributes the output looks like:

        "fileRetention": {
            "mode": null,
            "retainUntilTimestamp": null
        },
        "legalHold": "off"

and for an unauthorized one like:

        "fileRetention": {
            "mode": "unknown",
            "retainUntilTimestamp": null
        },
        "legalHold": "unknown",

2. BUCKET INCONSISTENCIES

A very similar inconsistency is visible in b2 get-bucket and b2 update-bucket. The latter one returns raw data as received from server (with isClientAuthorizedToRead).

3. BUCKET AMBIGUITY
   displaying default bucket encryption can be vague depending on key capabilities.

For a key that does not have the permissions to read bucket default encryption the output looks like:

    "defaultServerSideEncryption": {
        "mode": null
    }

And for a bucket with no default encryption and a key with reading capabilities it looks like:

        "defaultServerSideEncryption": {
            "mode": "none"
        },

The difference is hard to spot, but it's there.

I suggest treating these inconsistencies as bugs and fix them without releasing a major version of the CLI. The solutions I suggest:

1. use the b2 ls --json format everywhere
2. use the b2 get-bucket and b2 list-buckets --json format everywhere
   3.. introduce a possible value of "mode": "unknown" and for buckets with no default encryption use "mode": null.

[mjurbanski-reef]

"none" thing is also error prone. Eliminating that from interface will be a lot of work.
Same with "unknown"; IMO we should omit it from dict if we don't know it, otherwise the disparities between internal data structures and API lead to some weird errors.

related: Backblaze/b2-sdk-python#266

[agoncharov-reef]

I don't think we should omit field if we don't know its value. The contract should be crystal clear to users, and if they receive different structures based on some conditions, it would be a hell.
Maybe it would be hard to implement or something, but here we're talking about user experience with the product, it's more important than difficulty of implementation.