[Adding] Accountz monitoring endpoint and INFO monitoring req subject

[matthiashanel]

Returned imports/exports are formatted like jwt exports imports, even if they originating account is from config.
Fixes #1604

Signed-off-by: Matthias Hanel mh@synadia.com

I named the account specific subject INFO as it makes more sense than ACCOUNTZ.
ForCONNZ/SUBSZ we remain to have the plural even when scoped to the account, not so much for account itself.

Also setting update time on every update and account creation. (avoids empty values)
For consistency, setting incomplete when expired (dummy) account is created.
This is primarily to make the returned json make sense and look somewhat similar no matter the origin (jwt/cfg)

http://localhost:7222/accountz

{
  "server_id": "NDSVJWYHPIXEYV3PS66X4V2PUWWYVQVPQUJ35FZJRI5PN6QMWBHJ2MZH",
  "now": "2020-09-23T16:18:53.199956-04:00",
  "accounts": [
    "SYS",
    "$G",
    "USERS"
  ]
}

http://localhost:7222/accountz?acc=SYS

{
  "server_id": "NDSVJWYHPIXEYV3PS66X4V2PUWWYVQVPQUJ35FZJRI5PN6QMWBHJ2MZH",
  "now": "2020-09-23T16:19:56.311826-04:00",
  "account_detail": {
    "account_name": "SYS",
    "update_time": "2020-09-23T16:18:44.089969-04:00",
    "expired": false,
    "complete": true,
    "jetstream_enabled": false,
    "leafnode_connections": 0,
    "client_connections": 0,
    "subscriptions": 32,
    "exports": [
      {
        "subject": "$SYS.DEBUG.SUBSCRIBERS",
        "type": "service",
        "response_type": "Singleton",
        "approved_accounts": []
      }
    ],
    "imports": []
  }
}

[kozlovic]

Some comments about the json tags.

[kozlovic]

Here and almost all of them in AccountInfo, you seem to not use ,omitempty. Is there a reason? The boolean and int, if 0, could be omitted, which will make the JSON marshal smaller. Same for list of exports and imports (Exps, Imps, which by the way could probably be spelled out: Exports and Imports.

[matthiashanel]

I used omitempty sparingly because I imagine this to be used for debugging.
For this use case I imagine having values be explicitly listed makes more sense.
I used it only in cases where the source of the account makes a difference (jwt or config), which is also why I'll add it to this field.

[matthiashanel]

But I'll can add it everywhere. Your call.

[kozlovic]

But if explicitly listed but equal to the type uninitialized value (false for boolean, 0 for numbers, etc), you would really not know the difference. Meaning if you see say "expired: false", I am not even sure what that would mean to be set explicitly.

Or here, approved_accounts, if you don't see it it means it was nil. What difference (except for marshal result being bigger) would that make to get approved_accounts received as []string{} (or nil).

If you could give me an example of a case where having without omitempty would help debug as opposed to if the field had omitempty.

[matthiashanel]

Basically cut down on time spent trying to find out what should be there. If you don't think that matters I'll put omitempty on every field.

approved_accounts I added it already.

[kozlovic]

LGTM