NLSR

This is one possible solution:

At any node where NLSR is running, a repo instance should also be running. The repo will do two things:

1. Store LSAs. When NLSR fetches a new LSA, it will issue a repo insert command to store that data, and NLSR will issue a delete command for the previous LSA data. NLSR will then remember the current LSA to delete it next time.
2. Store keys. Since the number of keys is not all that great, we can do the same thing as above. Any time NLSR fetches a key, it will issue an insert command to store that data in the repo. No maintenance is necessary, since keys are not re-published regularly.

Brief discussion with Alex suggests that the repo is fit for this job, as it can insert and delete data correctly. This approach minimizes the amount of new code to incorporate into NLSR, essentially adding a table of "previous LSAs", and a few lines of code to issue the repo commands.

Latest NLSR does not converge without CS (with or without security), investigating.

LSA has an expiration time point i.e. after what time from now it will expire.
When node1 gets LSA from node2 and puts it into LSA storage it should schedule it expiry like:

(LSA-node2-expiration-timepoint) - now

What was implemented was opposite:

now - (LSA-node2-expiration-timepoint)

resulting in deletion of LSA from storage immediately

Testbed has the faulty version.

Integration test without CS passes after the fix:
https://gerrit.named-data.net/#/c/4639/