[F88] return the sanitized datastore key query count so omitted API l…

[peterjah]

…imits stay bounded

Breaking in effect:

• A client that omits count/limit previously received every key for the address; it now receives at most max_datastore_keys_query (500 in base_config/config.toml:46 and :127, for JSON-RPC and gRPC
  respectively).
• GetAddressDatastoreKeysResponse has only {address, is_final, keys} — no truncation flag. So such a client can't distinguish "that's all the keys" from "that's the first 500". It silently gets a short
  answer. That's the real sharp edge: a client with >500 keys under the queried prefix would need to switch to paginating via start_key, and nothing in the response tells it to.

Because we build the getDatastoreKeys endpoint recently, I am pretty confident that pagination is well supported by clients

[peterjah]

It appears massa-web3 Grpc does not implements the pagination.. but i dont think its used widely.
I will fix on massa-web3

[Leo-Besancon]

• A client that omits count/limit previously received every key for the address; it now receives at most max_datastore_keys_query (500 in base_config/config.toml:46 and :127, for JSON-RPC and gRPC
  respectively).

For this point, isn't it the same as #5189? What's the difference?

[peterjah]

• A client that omits count/limit previously received every key for the address; it now receives at most max_datastore_keys_query (500 in base_config/config.toml:46 and :127, for JSON-RPC and gRPC
  respectively).

For this point, isn't it the same as #5189? What's the difference?

Exact same thing it seems 😸

The thing i didnt pointed last time is that its conerns the newly created getDatastoreKey, that was build especially to replace the old get_addresses that was not paginated.
Pagination has been implemented day 1 on massa web3 (at least for the jsonRPC side...)
So it increase my level of confidence of pushing it

[peterjah]

As this PR seems a duplicate of #5189 i think i will report my comments there and close this one