[getdns-api] getdns_return_t for destroy methods

[Goyal, Neel]

>> 
>> The implementation can not.  But, the application using the
>> implementation/library *can* do it from within a callback, because the
>> callbacks are part of that application.
>> 
>> What we propose, is to let a getdns_context_destroy, when used from
>> within a callback, return GETDNS_RETURN_GOOD if the
>> library/implementation can deal with it, and GETDNS_RETURN_GENERIC_ERROR
>> if it can not.
>> 
>> Our implementation currently deals with it, but it is administratively
>> cumbersome (implementation wise) and therefore susceptible for bugs in
>> the future.  For robustness we would rather disallow it.
>
>OK, that makes more sense. How about this instead:
>
>getdns_return_t getdns_context_destroy(struct getdns_context* context);
>
>Returns destroys the context and GETDNS_RETURN_GOOD if the context
>exists.  If the context does not exist (for example, because it was
>previously destroyed), the function returns GETDNS_RETURN_GENERIC_ERROR.

This description feels a bit misleading to me.  If context is NULL, we can
return an error.  If context is already destroyed and not NULL, the code
will crash.  This is analogous to the double free problem that exists in C.

We are trying to disallow destroying a valid context within an API user¹s
asynchronous callback.  How about the last sentence becomes "If the
context cannot be destroyed (for example, within the body of a
getdns_callback_t), the function returns GETDNS_RETURN_GENERIC_ERROR.".