MSoM: enable session resumption

[XuGuohui]

As the title describes.

Problem

1. Session resumption is currentlly disabled on MSoM
2. When session resumption is enabled, it may use stale session info that is restored from backup flash, which results in long connection time.

Solution

1. Use the session info in KM4 RAM if it is valid.
2. Otherwise, use the session info in backup flash if it is valid.
3. Invalidate the session info in backup flash once it is restored.
4. If there is no valid session info, force a new handshake.

References

N/A

---

Completeness

• User is totes amazing for contributing!
• Contributor has signed CLA (Info here)
• Problem and Solution clearly stated
• Run unit/integration/application tests on device
• Added documentation
• Added to CHANGELOG.md after merging (add links to docs and issues)

[scott-brust]

This did work for me when entering/exiting ULTRA_LOW_POWER sleep on msom:

0000102293 [system] INFO: Cloud: connecting
0000102301 [system] INFO: Read Server Address = type:1,domain:$id.udp.particle.io
0000102307 [system] INFO: Loaded cloud server address and port from session data
0000102315 [system] TRACE: Address type: 1
0000102319 [system] TRACE: Cloud socket=0, family=2, type=2, protocol=17
0000102329 [system] INFO: Cloud socket=0, connecting to 18.214.12.187#5684
0000102336 [system] TRACE: 0 Bound cloud socket to lwip interface wl4
0000102344 [system] TRACE: Cloud socket=0, connected to 18.214.12.187#5684
0000102352 [system] TRACE: Updating cloud keepalive for AF_INET: 25000 -> 25000
0000102360 [system] TRACE: Applying new keepalive interval now
0000102366 [system] INFO: Cloud socket connected
0000102370 [system] INFO: Starting handshake: presense_announce=0
0000102376 [comm.protocol.handshake] INFO: Establish secure connection
0000102386 [comm.dtls] INFO: session has 0 uses
0000102392 [comm.dtls] INFO: (CMPL,RENEG,NO_SESS,ERR) restoreStatus=0
0000102396 [comm.dtls] INFO: out_ctr 0,1,0,0,0,0,0,16, next_coap_id=d
0000102402 [comm.dtls] INFO: restored session from persisted session data. next_msg_id=13
0000102412 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 2

Im not sure if this was by coincidence though that the session coap counters were still in sync?
Is this session restore supposed to work in other use cases beside STOP and ULTRA_LOW_POWER modes?
edit: It worked for me when calling System.reset()