refactor cache manager for yurthub

[rambohe-ch]

Ⅰ. Describe what this PR does

Backgound:

1. list requests from edge node have three types:

• type1: only get specified object by using fieldselector=metadata.name=xxx, the request path like: https://{ip:port}/api/v1/namespaces/default/pods?fieldselector=metadata.name=xxx
• type2: get a kind of objects by using fieldselector=spec.nodeName=xxx or labelselector=foo=bar, the request path like: https://{ip:port}/api/v1/pods?fieldselector=spec.nodeName=xxx
• type3: get all pods, the request path like: https://{ip:port}/api/v1/pods

2. cache manager handles list request in yurt-hub:

• in yurthub cache manager, we cache object one by one for list response, and the code link: https://github.com/openyurtio/openyurt/blob/master/pkg/yurthub/cachemanager/cache_manager.go#L336
• for type2 list request, query cache handle is the same as type3 list request, and the code link: https://github.com/openyurtio/openyurt/blob/master/pkg/yurthub/cachemanager/cache_manager.go#L167

problem:

• response for type3 list will not update all caches on local disk, so some deleted objects will remain in the cache.
• if a client on edge node has both type2 and type3 list request, a error will occur for type2 response.

solution:

1. replace local cache response instead of one by one cache for type2 and type3 list request
2. fix cache conflict for type2 and type3 list request, a client can only support one type list request for one resource in type2 and type3。and at present, kubelet/kube-proxy/flannel/coredns have only one type list request for one resource in type2 and type3.

Ⅱ. Does this pull request fix one issue?

Ⅲ. List the added test cases (unit test/integration test) if any, please explain if no tests are needed.

Ⅳ. Describe how to verify it

make test
make all
and make sure yurthub cache manager can work

Ⅴ. Special notes for reviews

[Fei-Guo]

If error happens, do we have retry mechanism? If not, do we have mechanism to do consistency check?

[rambohe-ch]

I have not seriously thought about how to guarantee that object can be cached successfully. so i'd like to keep this subject as a TODO item. and we can solve it in the soon future.

[Fei-Guo]

Can you explain the purpose of having listReqCollector?

Also, can you give an example that "len(k) > len (key) " and an example for "len(k) < len(key)"?

[rambohe-ch]

1. because func queryListObject() will get all pods for both requests instead of getting pods by request selector. so cache manager can not support same path list requests that has different selector. for example:

• request1: http://{ip:port}/api/v1/default/pods?labelSelector=foo=bar
• request2: http://{ip:port}/api/v1/default/pods?labelSelector=foo2=bar2

2. because func queryListObject() will get all pods for both requests instead of getting pods by request selector. so cache manager can not support getting same resource list requests that has different path. for example:

• request1: http://{ip/port}/api/v1/pods?fieldSelector=spec.nodeName=foo
• request2: http://{ip/port}/api/v1/default/pods?fieldSelector=spec.nodeName=foo

in order to solve the above two problems, we need listReqCollector to keep list request info, and based on listReqCollector to verify list requests can cache or not.

Also, can you give an example that "len(k) > len (key) " and an example for "len(k) < len(key)"?
the second above example.