RestProxyCall: Handle soup_error_new() failures

If given a URI it can't parse, soup_error_new() will return NULL.

https://bugzilla.gnome.org/show_bug.cgi?id=728953
Use g_hash_table_replace() in rest_params_add()

rest_params_add() is currently using g_hash_table_insert() to add
the passed in parameter in the parameter hash table. The key which
is used is owned by the associated value.

When using rest_params_add to replace an already existing parameter,
the existing value will be freed with rest_param_unref().

However, g_hash_table_insert() does not replace the key when it already
exists in the hash table: "If the key already exists in the GHashTable
its current value is replaced with the new value... If you supplied a
key_destroy_func when creating the GHashTable, the passed key is freed
using that function."

This means that after replacing an already existing parameter, the
corresponding key will still be the old one, which is now pointing
at freed memory as the old value was freed.

g_hash_table_replace() ensures that the key will still be valid, even
when replacing existing parameters:
"Inserts a new key and value into a GHashTable similar to
g_hash_table_insert(). The difference is that if the key already exists
in the GHashTable, it gets replaced by the new key."

https://bugzilla.gnome.org/show_bug.cgi?id=665716
Ignore '/' at beginning of REST function

When building the HTTP URL to access for a REST operation,
RestProxyCall::prepare_message, a '/' at the end of the base URL
is ignored, but a '/' at the beginning of the REST function is not.

When interacting with the oVirt REST API, I often end up building calls
with for example 'https://ovirt.example.com' as the base URI, and '/api/vms/'
as the function, which then leads to an URI with 2 '/':
'https://ovirt.example.com//api/vms'

https://bugzilla.gnome.org/show_bug.cgi?id=728952
Fix rest_xml_node_print name in gtk-doc annotation
Add rest_proxy_call_get_function()

There are rest_proxy_call_[gs]et_method() methods, a
rest_proxy_call_set_function() method, but no corresponding getter.
Adding it makes the API more consistent.

https://bugzilla.gnome.org/show_bug.cgi?id=708358
Allow to modify REST function in serialize_params vfunc

RestProxyCall::prepare_message() calls the serialize_params vfunc
so that child classes can serialize the call parameters in whichever
way they want.
One way of doing that could be to append the parameters to the URI
that is called (http://example.com?param1=value1;param2=value2).
However, the URI to call is determined at the beginning of
prepare_message(), and is not refreshed after calling
RestProxyCall::serialize_params(), so it's not possible to
append parameters to the URI that is going to be called.

This commit rebuilds the URI to call after calling serialize_params()
in case it has changed.

https://bugzilla.gnome.org/show_bug.cgi?id=708359
Add rest_proxy_add_soup_feature()

This function can be helpful if one wants more control over libsoup
features than what librest simple API provide. For example, to get full
access to libsoup cookie API (say to be able to add arbitrary cookies to
the soup session), one can do:

RestProxy *proxy = g_object_new(REST_TYPE_PROXY,
                                "url-format", url,
                                "disable-cookies", TRUE,
                                NULL);
SoupSessionFeature *cookie_jar = SOUP_SESSION_FEATURE(soup_cookie_jar_new ());
rest_proxy_add_soup_feature(proxy, cookie_jar);

It's then possible to use all the soup_cookie_* methods to deal with
cookies.

https://bugzilla.gnome.org/show_bug.cgi?id=728340
Add libsoup to gir includes

Since the public API now references a type from libsoup, we need
to add Soup-2.4.gir to Rest_@API_VERSION_AM@_gir_INCLUDES.

https://bugzilla.gnome.org/show_bug.cgi?id=728340
More improvements to rest_proxy_call_get_params API doc
flickr: Fix function setting regression

Since commit c66b6d, RestProxyCall::url is regenerated after calling the
RestProxyCall::prepare virtual method. This breaks the flickr code as
it needs to reset RestProxyCall::url in order to remove the function
from it.
It used to do that by directly accessing RestProxyCall private
data. Since c66b6d, this can be solved using only public methods as
if the function is reset on the RestProxyCall in ::prepare, ::url will
be regenerated to reflect that after ::prepare and ::serialize_params
have been called.

https://bugzilla.gnome.org/show_bug.cgi?id=708359
lastfm: Fix function setting regression

Since commit c66b6d, RestProxyCall::url is regenerated after calling the
RestProxyCall::prepare virtual method. This breaks the lastfm code as
it needs to reset RestProxyCall::url in order to remove the function
from it.

It used to do that by directly accessing RestProxyCall private
data. Since c66b6d, this can be solved using only public methods as
if the function is reset on the RestProxyCall in ::prepare, ::url will
be regenerated to reflect that after ::prepare and ::serialize_params
have been called.

https://bugzilla.gnome.org/show_bug.cgi?id=708359
oauth: Make sure RestProxyCall::url is set before using it

The oauth "prepare" step needs RestProxyCall::url to be set, but since
commit c66b6d this is only set after the "prepare" and
"serialize_headers" methods have been called. As it's
better if OAuthProxyCall do not directly access RestProxyCall private
data, this commit adds a getter to RestProxyCall which will be used
to make sure RestProxyCall::url is set when OAuthProxyCall::prepare
needs it.

https://bugzilla.gnome.org/show_bug.cgi?id=708359
oauth: Remove direct access to RestProxyCallPrivate

OAuthProxyCall was directly accessing private RestProxyCall data. The
same functionality can be achieved using only librest public API, so
let's use that instead.

https://bugzilla.gnome.org/show_bug.cgi?id=735919
flickr: Remove direct access to RestProxyCallPrivate

Now that FlickrProxyCall no longer directly modifies RestProxyCall::url,
it's trivial to remove all accesses to RestProxyCallPrivate.

https://bugzilla.gnome.org/show_bug.cgi?id=735919
lastfm: Remove direct access to RestProxyCallPrivate

Now that LastFMProxyCall no longer directly modifies RestProxyCall::url,
it's trivial to remove all accesses to RestProxyCallPrivate.

https://bugzilla.gnome.org/show_bug.cgi?id=735919
Move RestProxyCallPrivate to rest-proxy-call.c

It was in a separate rest-proxy-call.h header which allowed derived
classes to access RestProxyCall private data without any control.
Better to go through explicit methods to do that.

https://bugzilla.gnome.org/show_bug.cgi?id=735919
Fix URL used for flickr rest calls

https must be used, and the correct URL for uploads is up.flickr.com

https://bugzilla.gnome.org/show_bug.cgi?id=735920
tests: Don't call g_type_init() on newer glib

This is deprecated and causes a compile warning

https://bugzilla.gnome.org/show_bug.cgi?id=735921
tests: Don't call soup_message_headers_get with newer libsoup

This is deprecated and causes compile-time warnings

https://bugzilla.gnome.org/show_bug.cgi?id=735921
tests: Remove unused 'session' variable

https://bugzilla.gnome.org/show_bug.cgi?id=735921