Add deposit account limits API resource

[trevornelson]

Adds a new AccountLimits resource for returning an account's limits and current usage against said limits. I decided to decouple this more strongly from the Unit API's schema, which meant I had to override the default API JSON casting abstractions that other resources in the library have. There's a few reasons for this:

• The limits are broken up into subobjects for each resource (e.g. ach or checkDeposit). Each of these sub-objects have their own unique schema, which means they'd each need to have their own types defined here in order to fit with how the API JSON gets cast to objects. That felt a lil sloppy to me- I'd rather the consumer get a simpler interface.
• Limits and current usage are stored in separate objects in the API. I was kind of fighting the pre-existing ApiResource's casting.
• These are all read only fields, so we really only care about mapping from the API to the library resource. Since they're read only, a lot of the value of the casting abstraction isn't really helpful.

[linear]

RET-3414 Show ACH limits in the Dashboard

[trevornelson]

Kinda silly, but Rubocop was complaining about too many things. I couldn't get around AbcSize as it is.

[ianyamey]

It works, so I'm okay shipping this. However, we'd be letting in some of our own usage / customizations creep into the base library. I've left some suggestions on how we might keep the implementation closer aligned with Unit's docs

[ianyamey]

Since there was quite a bit of overloading required to mack this quack correctly, what do you think about moving this into the Accounts API resource?

class DepositAccount < APIResource
  def limits
    @cached_limits ||= connection.get("#{resource_path(id)}/limits")
    Types::Limits.cast(cached_limits)
  end
  
  def ach_debit_daily_limit
    limits.dig('ach', 'debit', 'daily')
  end

  def ach_credit_daily_limit
    limits.dig('ach', 'credit', 'daily')
  end
  ...
end

[ianyamey]

While it's nice intent to remap the Unit structure into something more consumable, it wondering if keeping more closely aligned to the API docs will make this easier to maintain (and fewer edge cases/inconsistencies in the implementation).

You could still remap things to be friendlier in the API consumer (for us, that means in our app) rather than the base library

[ianyamey]

This is much cleaner. While it's got more boiler plate code, it's more aligned with the Unit API 👍 👍

[ianyamey]

Suggested change

	return @limits if @limits
	@limits = Types::AccountLimits.cast(
	self.class.connection.get("accounts/#{id}/limits")
	)
	@limits ||= Types::AccountLimits.cast(self.class.connection.get("accounts/#{id}/limits"))