Cache support API to improve clustered data reads performance

Clustered data reads may be time-consuming, therefore a requirement for a cache was raised by netvirt and genius, yet this capability can be useful across odl projects.

This cache should be initially populated and maintained going forward.

discussing this topic in mdsal-dev list, a suggestion to enhance the current API to support this requirement was made:

https://lists.opendaylight.org/pipermail/mdsal-dev/2016-December/000881.html
https://lists.opendaylight.org/pipermail/mdsal-dev/2016-December/000859.html
https://lists.opendaylight.org/pipermail/mdsal-dev/2016-December/000853.html
https://lists.opendaylight.org/pipermail/mdsal-dev/2017-January/000921.html

More info, copied from Robert's mail:
There is one more problem, which are wildcard DTCLs. TstanceIdehese are allowed to be wildcarded on any YangInntifier component corresponding to a keyed list.

list foo {
leaf foo;
key foo;

list bar {
leaf bar;
key bar;

container baz

}
}

All of these are valid subscriptions:
/foo
/foo/foo[foo=*]/bar
/foo/foo[foo="abc"]/bar/bar[bar=*]
/foo/foo[foo=*]/bar/bar[bar=*]/baz
/foo/foo[foo="abc"]/bar/bar[bar="abc"]

The first two do not have a binding representation, but they are valid at DOM level. All except the last one are wildcards.

I think the current discussion is making an implicit assumption what the relationship between the registration YIID and the one reported to the listener. With concrete YIIDs, they are YangInstanceIdentifier.equals().
Wildcards are expanded as data is discovered, hence there is no such relationship – except they share the prefix leading to the first wildcard.

It is critical the API contract of the proposed method is defined with this difference in mind.

===========================================================================

Please note that this issue is different from:
https://bugs.opendaylight.org/show_bug.cgi?id=2504

The difference is that this issue makes an assumption on follower locality, while the cache does not. This is an important distinction in clusters where there is no shard presence (leader/follower) on some nodes.