migrate to sysrepo 1.4

Main part of #1077 (closed)

This branch now compiles and passes unit tests when compiled with sysrepo v1.4.140 + libyang v1.0.240. Here's what changed since sysrepo v0.7.9:

Architecture

• the sysrepod daemon no longer exists. The code that it was running now lives inside Kea and resources that were in-memory in sysrepod are now either in-memory in kea-netconf, or - more impactfully - they are external resources
• One such external resource is shared memory. What were previously in-memory mutexes are now system-wide semaphores that reside in /dev/shm. These are persistent over reboots. A locked semaphore can remain locked if kea-netconf doesn't clean up after itself which could potentially happen in a crash. This would then lead on kea-netconf not being able to start again because a required resource is locked. The recommended workaround (https://github.com/sysrepo/sysrepo/issues?q=shm_clean) for this is to run "make shm_clean" in the sysrepo sources whenever you find yourself in this situation. What this does can be easily extracted from their CMakeLists.txt:

# phony target for clearing sysrepo SHM
add_custom_target(shm_clean
    COMMAND rm -rf /dev/shm/sr_*
    COMMAND rm -rf /dev/shm/srsub_*
    COMMENT "Removing all volatile SHM files prefixed with \"sr\""
)

You can create your own script that does

rm -rf /dev/shm/sr_*
rm -rf /dev/shm/srsub_*

so that you don't depend on sysrepo sources. They claim in one of their Github issues that this should not occur in production. This is a reasonable proposition. We foolproof Kea against crashes anyway. And that's the only thing that could cause this lock leak. Apart from sudden power outages too...

• Before, you could set an element, immediately do a get on it afterwards, and you would see the changed value. That's what most unit tests relied on. Now you have to Session::apply_changes() (previously Session::commit()) before the same session can see the data. In other words, sessions have the same visibility even with regards to their own changes. This seems like a bi-product of getting rid of sysrepod.
• The above point forces us to clean up after ourselves in unit tests. Since committed changes are persistent over different unit tests, even in the candidate datastore. A delItem() is done on the toplevel node in SetUp and on TearDown and the test fixtures had to be rewritten so that the model is fed to them on construction not at a later time. But they're prettier now.

Compilation

• libSysrepo-cpp.so has been renamed to libsysrepo-cpp.so. As a result, the -lsysrepo-cpp flag needs to be passed now instead of -lSysrepo-cpp.
• -pthread -lpcre -lev -lavl -lprotobuf-c seem to not be required anymore
• -lyang-cpp is an additional requirement

Code changes

• the sr_module_install_subscribe() function has been removed. We were using to log module installations. Subscribing to module installations can now be done using the notifications API instead - is what I gather from their three-word line documentation, but I have not been able to do so. This feature has been dropped.
• 0.x had a Callback class that you would use to subscribe to events. The Callback class has been removed and the subscription functions now accept a function. They use a lambda in their examples (https://github.com/sysrepo/sysrepo/blob/v1.4.140/bindings/cpp/examples/cpp_application_changes_example.cpp#L140-L169).
• New event SR_EV_UPDATE that allows you to modify configuration mid-flight.
• SR_EV_VERIFY has been renamed to SR_EV_CHANGE.
• SR_EV_APPLY has been renamed to SR_EV_DONE.
• sr_commit has been renamed to sr_apply_changes.
• sr_notif_event_t is now sr_event_t.
• Config changes come with an xpath to the modified element. We still don't use it.

Changes in how Kea reacts with Sysrepo:

• When running unit tests, /dev/shm/sr* and the sysrpeo repository need to be owned by the user running the unit tests. Since some unit tests fail, if you run as root, during this time, you should have the above resources owned to the non-root account that is running the unit tests.
• When running in conjunction with kea-dhcp[46], if you run as a non-root user, kea-netconf will fail to write to the unix socket that has kea-dhcp[46] at the other end. So the above resources need to be chowned to root again.
• An exception is thrown now when setting a container via the config API. Only leaves can be set and their preceeding containers are set automatically. Same for deleting.