Add collection support

[chasedog]

Adds support for:

/api/v1/collections/add_post_to_collection
/api/v1/collections/collection
/api/v1/collections/create_collection
/api/v1/collections/delete_collection
/api/v1/collections/subreddit_collections

To-do:
/api/v1/collections/remove_post_in_collection
/api/v1/collections/follow_collection
/api/v1/collections/reorder_collection
/api/v1/collections/update_collection_description
/api/v1/collections/update_collection_display_layout
/api/v1/collections/update_collection_title

This branch is based on chasedog:fix-build-and-update-packages. I will rebase once that's merged.

[CrustyJew]

Does this actually return the errors from Reddit properly? That's been something I've been meaning to fix up. It also needs an HTTP status code preferably.

[chasedog]

Yes, it does, but only for the new endpoints I've implemented. But yeah, I agree the code in ExecuteRequestAsync needs to be cleaned up to expose the errors instead of swallowing an exception.

Example response when trying to delete a collection that doesn't exist: {"json": {"errors": [["INVALID_COLLECTION_ID", "That collection doesn't exist", "collection_id"]]}} but the status code is 200.

"errors" is an array of arrays... kinda weird, but the consumer can do whatever with it

[jkrejcha]

@CrustyJew It appears RedditHttpException has the status code built in. Perhaps eventually having an Error class that can be used across the board?

[CrustyJew]

@chasedog @jkrejcha I think it would be better to get these rolled together so you have one exception type and can determine if it is an HTTP status code issue or a reddit result issue.

[jkrejcha]

The great thing about the reddit API is that it seems to be a combination of both, either one, none, or sometimes a completely different error code dependent on whether you're accessing via the site or via the JSON API. There does need to be handling of errors of some sort. RedditHttpException should probably inherit from RedditException IMO but it's hard to say.

[CrustyJew]

What's the purpose behind having this as an interface here?

[chasedog]

It's for PopulateObjects to have a way to set the web agent for each object. So when you fetch the collections, you can do collection operations (e.g. AddPostAsync) directly to the object instead of passing in the web agent, for example.
Do you prefer the web agents to be set after populating the objects here:

var result = Helpers.PopulateObjects<Collection>(json, WebAgent);
foreach (var collection in result)
    collection.WebAgent = WebAgent;
return result;

Or pass in Action<T> (e.g. x => x.WebAgent = WebAgent) that gets called after the item is populated?

Or something else?

[CrustyJew]

I'm thinking it may make more sense just to make the WebAgent settable by default instead of having a specific interface for it.

[jkrejcha]

Why can't PopulateObjects just use the Thing's static Parse() method instead of creating a new interface?