Generalize endpoint options

[Marcin S.]

From #10 (comment):

Looking at this MR more I'm wondering if it makes more sense to rename this to APIRoute and add it to the ConnectionOptions.

That would allow us to generalize the code even more. Unless there is a plan to move the parameters like name, id, skykeytype into their corresponding options struct it seems unnecessary to be defining an Options struct for each endpoint.

Then this line becomes even more clear

url := makeURL(opts.PortalURL, opts.APIRoute)

To be able to define the defaults easily we could have just two structs.

ConnectionOptions struct {}
APIRouteOptions struct {}

I'm thinking that there are a number of common API parameters that could be included in the APIRoutes eventually, like async root force etc.

Then the defaults can be defined as

DefaultGetSkyKeyOptions = APIRouteOptions {
  ConnectionOptions: defaultConnectionOptions,
  APIRoute: "/skynet/skykey",
}

My thoughts:

I think we could have the APIRoute as a field in ConnectionOptions which we rename to just Options and the options for each endpoint can compose on top of it. I want to keep a separate option struct per endpoint though for better type-safety and future-compatibility. It would also be weird if AddSkykey took an Options while Upload took UploadOptions

I'm thinking that there are a number of common API parameters that could be included in the APIRoutes eventually, like async root force etc.

Most of these don't apply to many of the endpoints. This is what we do in Python and Javascript atm unfortunately. But I would like to restrict the users a bit e.g. they shouldn't be able to set force if the endpoint doesn't take it.