Implement transparent client pattern and middleware error handling

[andrii-balitskyi]

Closes #137

• Add response middleware
• Remove base client
• Remove request_seam methods in favour of using faraday client directly
• Support [] syntax on DeepHashAccessor instances
• Adjust action attempt polling to the new logic
• Bump the generator to 1.14.10 to adjust routes
• Fix tests

[razor-x]

What does this do? Why is it defined as a private function but called here?

[andrii-balitskyi]

initialize_routes is an internal method to set up route clients by making available @client and @defaults for them. SingleWorkspace can access private initialize_routes because Routes module gets included in the class. While the method will exist on instances, being private it can only be called internally (inside the class/module methods) and not from outside code, unlike public methods like 'devices', 'access_codes' etc. which can be called by anyone using the instance.

[razor-x]

Why is this method needed though vs just putting the code inline? I think I must be missing something obvious.

[andrii-balitskyi]

By including it inline, you mean to include the code bellow in the SingleWorkspace class?

def access_codes
  @access_codes ||= Seam::Clients::AccessCodes.new(client: @client, defaults: @defaults)
end

...

We could have done that, but we decided to generate route-related stuff, so I placed the clients under the Routes module (which is generated) so that we won't need to manually update the SDK when new namespaces are introduced in the Seam API. Let me know if you have a better approach in mind.

[razor-x]

I was wondering why not to just do

      @client = client
      @defaults = defaults

But now I understand what this is doing. Basically this module only works if mixed into classes that define @client and @defaults. And this method is helping clarify that requirement.

I wonder if there is a more standard pattern to handle this.
I think it may be what this question is asking about https://stackoverflow.com/questions/12586051/initializing-instance-variables-in-mixins