简单介绍ProbePicker的实现。
1. 基本介绍
用于把多个Cache client合并成一个：
2. diplomacy node
ProbePicker的diplomacy node是一个适配器节点，用于与上下游节点连接，并进行参数传递。
这里下游节点的参数向上游节点传递时不做改变；上游节点的参数向下游节点传递时进行了适配，把可以合并处理的cache client的参数进行了合并，这样下游节点看到的ProbePicker的client参数中就少了一部分被合并掉的client。
1) clientFn
把原clients中的元素从右向左逐个进行combine，合并后的结果作为新的clients参数：
2) combine
这里的假设是连续的client访问的地址集合（visibility）是有序的：
a. 若head和next有重叠，则不能合并；head的意思是能够合并的元素的头一个，既然不能合并，那么head就失去了其意义，将其加入到output即最终的clients序列中，而下一个元素成为接下来要检查的能够合并的元素的头一个元素，即下一次combine中的head。
b. redact用于把head和next的sourceId/nodePath和visibility忽略掉进行比较，要求其他的域如name/requireFifo/supportsXXX等都需要相同；
c. 合并则是将head和next两个的sourceId和visibility进行合并；
3) 合并sourceId
head和next的sourceId具有怎么样的关系？
a. 重合：部分重合或者全部重合；
b. 不重合；
3. lazy module
lazy module用于实现ProbePicker的内部逻辑：
因为diplomacy node中可能把上游节点的多个clients合并到一起了，所以下游节点看到的sourceId实际上也是合并之后的，即下游节点发起Probe消息时，使用的是合并之后的source值。需要ProbePicker把这个source值区分成合并前的某一个client再转发给上游节点。
1) 成对的输入边和输出边
2) 默认直连
3) 区分source
a. edgeIn.client.clients.size是输入边的clients的数量，即ProbePicker看到的上游节点的clients的数量；edgeOut.client.clients.size是输出边的clients的数量，即ProbePicker的下游节点看到的ProbePicker的clients的数量。两者相等，表明没有进行合并；两者不等，则表明进行了合并，则需要对source域进行区分；
b. 判断source属于哪一个client：edgeOut.client.clients.map(_.sourceId contains out.b.bits.source)
c. 如果合并前只有一个client的sourceId被合并后的client包含，则表明这个client没有与其他client进行合并，所以无需区分；
d. 否则需要根据地址确定是属于哪一个合并前的client（这些client的visibility不重叠），而后转换为对应client的sourceId：
