是否考虑增量配置更新

1. JAVA客户端当前实现是longpolling+全量拉取
在微服务场景下，一般是针对指定app级别下面所有kv的监听，一旦有一个kv发生变化，服务端就会进行一次全量的推送。
目前方案存在的问题是：如果app级别下面存在的kv数量过多或者过大，在客户端实例数量较多的情况下进行一次全量推送会给客户端和服务端的缓冲区以及内存带来较大压力，对于网络也不友好。

2. 可以考虑客户端在进行请求时header携带increment=true来决定是否进行增量更新模式
如果开启增量模式，kie可以选择在数据发生变化时只推送发生变化的kv。

No files or tests are named. Start by tracing the Java client's long-polling request and the server path that performs full configuration pushes; clarify the protocol semantics for the increment=true header and changed-key payloads. Done should mean the opt-in mode is specified and supports pushing only changed key-value entries without changing the existing full-fetch behavior.

Written by the indexing model from the issue text.