Factorize out socket management from LwM2M engine

[tautologyclub]

In a lot of use cases, it would be preferable if the application could handle the connection management itself, rather than offloading everything onto a LwM2M engine. This would enable us to use the LwM2M module(s) as lib/s which would give the implementation a lot more flexibility in terms of

• more fine grained connection control (for power management)
• implementing optional features from the OMA spec (such as queue mode, protocol muxing, alternative transport methods such as serial, multiple server connections, etc)
• omitting/modifying parts of the spec to fit the project requirements
• enable testability of the implementation (currently there are no test suites for lwm2m)

In broad strokes, we'd require

• Separation of network/connection related functionality and "library-like" functionality into separate modules
• a CONFIG_LWM2M_SOCKET_MANAGEMENT Kconfig that can be switched off (defaulting to y would perhaps be natural however)
• Expose lwm2m_engine.c:handle_request(...) as a public, not static, function (appropriately namespaced ofc)

But there's also a clear risk that there's functions with "silent" dependencies on the fact that the lwm2m engine does socket management. One example is lwm2m_obj_firmware_pull.c and any other module which uses lwm2m_send_message().

[tautologyclub]

@mike-scott

[carlescufi]

@tautologyclub I am closing this because the LWM2M engine in general has seen major refactoring since this issue was created. Please reopen if you think this is still applicable.