Solve nil pointer derefrence

[ersonp]

Did you run make format && make check?
yes

Fixes #740

Changes:

• Initialised Summary struct inside ExtraSummary

How to test this PR:

1. Setup hypervisor
2. Connect visor to the hypervisor
3. Disconnect visor
4. Check hypervisor logs

[jdknives]

@ersonp this solves the panic, but leaves us with another issue:

Sometimes, the visor that got shutdown is not shown as offline and the frontend cant reload anymore.

log.txt

[ersonp]

I have managed to fix that issue by sending empty fields. But I think that's unnecessary data, and would be better if there is a fix from the UI side. Having said that, it might not make a lot of difference and we can keep using this fix.

[ersonp]

@i-hate-nicknames can we use extraSummaryResp with IsHypervisor and DmsgStats fields instead of using a new object extraSummaryWithDmsgResp.
Also, I feel like few of the method names can be changed for better clarity like: getVisorsExtraSummary to getAllVisorsSummary and makeExtraSummaryResp tp generateSummary.

[jdknives]

@ersonp @i-hate-nicknames just a general comment from my side:

While reviewing the fix from Erson, I thought that the naming for the various summaries could be clearer. Currently it looks to me like there are multiple summaries which leads us to weird constructs such as ExtraSummaryWithDmsgResponse etc. In this case I think it may be better to call the most expansive (informative and detailed) struct the Summary and call the current Summary object Overview or Details. Maybe there is a better option as well.

[i-hate-nicknames]

Yes, feels like it definitely needs some refactoring. There are multiple levels of extra that seems to have been added over time. Visor has summary and extra summary, and hypervisor has his own extra summary, plus response wrappers around visor summaries:
hypervisor provides:

1. visor.Summary (via getVisor()), wraps in summaryResp
2. visor.ExtraSummary (via getVisorSummary()), wraps in extraSummaryResp
3. its own extra summary (extra-extra now?) (via getVisorsExtraSummary()), extraSummaryWithDmsgResp
   There are some overlaps between those structures but not always, e.g. visor.ExtraSummary Dmsg is different from Dmsg in extraSummaryWithDmsgResp. So we cannot simply embed one into other.

I would propose:

1. Remove Dmsg from visor.ExtraSummary. This field is not populated by visor api, so there is no reason to have it there.
2. Investigate why do we need dmsg stats for all visors in getVisorSummary, since we are asking for stats of a single visor.
   In case we don't need that data, extraSummaryWithDmsgResp and extraSummaryResp become equivalent and the former
   can be removed
3. Factor out TCPAddr and Online fields into its own struct, maybe smth like NetworkStats?
4. Rename summary to overview like @jdknives suggested, and extra summary to just summary