Rename `accountStatus`/`leaseStatus` --> `status`

[eschwartz]

Currently, our account and lease JSON payloads have accountStatus and leaseStatus fields. The naming is redundant, since the field is a property of the account or lease object.

Also, it's inconsistent with our API GET query param syntax, which accepts, for example, GET /accounts?status=Ready

PR #236 proposes to rename the query param to GET /accounts?accountStatus=Ready. If we're making a breaking change here, I'd rather make a change to the API payload than the query parameter.

---

Note that we do have internal systems at Optum relying on these API interfaces. And DCE CLI may rely on these params as well. I'd recommend that if we make a change here, we have at least one release that's backwards compatible (ie. contains both status and accountStatus fields). This will give us time to update logic in our clients.

eg GET /accounts?status=Ready

[
  {
     id: "123456789012",
     status: "Ready",
     accountStatus: "Ready",
     ...
  }
]

[eschwartz]

To be clear, I do not think we should modify our DB tables. I don't want to deal with a migration. Just how we serialize to JSON -- should be as easy as modifying the json:"status" tags, and updating our functional tests

[marinatedpork]

The goal of that change is not to remove stuttering, but to achieve consistency between column names in the tables, property names in the payload, and query parameters in requests. Changing it to status in the payload would not achieve consistent naming between API and DB. If we want to move to remove stuttering from the payload, then we should also remove it from the DB.

[eschwartz]

would not achieve consistent naming between API and DB.

@marinatedpork I'm more concerned about normalizing the interface for end-users. Being in sync with the DB field names would be nice, but I don't think it's worth doing a database migration to get there.