Consistent style in the ABI (expanded vs minimal)

[PiotrSikora]

During the initial development, we went through a lot of back-and-forth both expanding and minimizing the ABI surface (e.g. get_buffer_bytes(buffer_type) vs get_http_request_body_chunk() and similar, set_shared_data(NULL) vs remove_shared_data()), both internally and during Envoy upstreaming process.

The version that was initially merged into Envoy, and which the ecosystem ossified around, ended up with some unfortunate inconsistencies (using both: expanded proxy_{get,add,replace,remove}_header_map_value, and minimal proxy_set_buffer_bytes(start, offset) or proxy_set_shared_data(NULL)).

We should clean this up and stick to one style.

While I don't have strong preference one way or the other, note that splitting features into groups (#57) and having specialized context types with their own hostcalls (#9) probably means that we should be expanding the ABI surface instead of minimizing it.

@mpwarres @martijneken @leonm1 @wbpcode @thibaultcha any thoughts?

[mpwarres]

I don't feel strongly, but as discussed offline, my preference would be for separate hostcalls, to make usage/dependency visible to static analysis, and also to leave open flexibility for variation if needed.

[PiotrSikora]

Per discussion from the ABI sync meeting on 2/19, we've decided to go with the "minimal" variants, otherwise the number of hostcalls would increase significantly.

For example, expanded proxy_get_header_map_pairs(proxy_map_type_t) would require 8x hostcalls - proxy_get_request_header_map_pairs, proxy_get_response_header_map_pairs, ..., expandedproxy_get_buffer_bytes(proxy_buffer_type_t) would require 9x hostcalls, and so on... Same for setters.

Simiarly, using 0 (NULL) in place of return buffer in getters will be used for exists calls, and using 0 (NULL) in place of new value in setters will be used for delete calls.