Add queue resource

[Morganamilo]

Closes #11

[Morganamilo]

So all of the queue stats are going to be changing on the fly. How will terraform react to this? I don't know how to use a queue so I've not been able to test.

[kavalerov]

After looking at this I am actually wondering if we should remove the stats fields from the provider completely. My reasoning is the following.

The main purpose of the Able Terraform provider is to enable people to configure their Ably apps programmatically, using infrastructure as a code. This enables customers to replicate their configuration easily, have it under version control (which enables things like change management via change reviews), and have a consistent way of managing their infrastructure stack. Infrastructure as a code should describe the configuration of the infrastructure, not the details of their internal operation.

These queue stats fields on the queues object serve a completely different purpose and use case - customers would use them to observe the operation of the queue. They are read only - even if you look at Control API reference, only the following is included in the payload for creating or updating the queue:

{
  "name": "My queue",
  "ttl": 60,
  "maxLength": 10000,
  "region": "us-east-1-a"
}

Therefore I suggest we expose only these writable fields in the queues resource, and do not expose read only and dynamically changing ones.

[Morganamilo]

Sounds good. Obviously not all read only fields, as ID and stomp_destination have value :P

But as some one who doesn't know too much terraform stuff this sounds valid.

[kavalerov]

Yeah, I guess I meant more "dynamically changing read only fields", or something like that - i.e. ID shouldn't really change throughout operation of the queue, as well as stomp_destination I think.