Add truncation to status reporting

[kdorosh]

similar to solo-io/solo-kit#523

we should protect etcd from gloo mesh as a potentially buggy or erroneous client. if resources get too large, we can take down their k8s cluster itself and put GM into a state where it cannot start.

the proposed solution:

• try to truncate status before writing
• if that fails and still too large, don't write the status

cc @Sodman @ilackarms @EItanya (I'm told this may not be an issue for GM, but not sure why we are so confident)

@nrjpoddar as part of stability effort

[Sodman]

The design for Gloo Mesh statuses was that the entire status would be written to and held in redis, but the status written back to the actual CRs in k8s would be truncated/trimmed to a reasonable size, eg max 10 entities. For large statuses, users can get more information via the UI, and we also plan to add tooling to meshctl to help with this.

Looking at the code however, I'm not sure this has been implemented yet, at least I'm not seeing the truncation logic where I'd expect it.