Remove some tuple usage

[spuun]

WHAT is this pull request doing?

It's very annoying when tuples are nested in tuples and you need to do value[0][1]. This will change BindingKey and QueueBinding from Tuple to struct.

Interesting is that

alias QueueBinding = Tuple(BindingKey, Exchange)

didn't force the order of the values based on type, see

lavinmq/src/lavinmq/vhost.cr

Lines 365 to 372 in 0603aa9

	def queue_bindings(queue : Queue)
	iterators = @exchanges.each_value.map do |ex|
	ex.queue_bindings.each.select do |(_binding_args, destinations)|
	destinations.includes?(queue)
	end.map { |(binding_args, _destinations)| {ex, binding_args} }
	end
	Iterator(QueueBinding).chain(iterators)
	end

where the orders in line 369 are swapped compared to QueueBinding

One problem with this refactoring is that Hash#[](key) isn't type, which means we don't get any compile time error when we access our binding hashes with the old value, so there's a risk i've missed change the type in one place or two.

HOW can this pull request be tested?

Run specs

[spuun]

IMO we should avoid Tuple and NamedTuple everywhere.

[spuun]

I monkey patched Hash locally and didn't find anything related to this change.

[snichme]

This will conflict with #786 but I like the approach of using a struct instead of an alias. How about I introduced the struct in mr PR instead?

[carlhoerberg]

IMO we should avoid Tuple and NamedTuple everywhere.

Totally do not agree. In this case it makes sense, but there are definitely cases where Tuple or NamedTuples is the better option.

[spuun]

IMO we should avoid Tuple and NamedTuple everywhere.

Totally do not agree. In this case it makes sense, but there are definitely cases where Tuple or NamedTuples is the better option.

Well, I'm generalizing a bit. But I think that many uses of NamedTuple can be a struct instead.

[spuun]

This will conflict with #786 but I like the approach of using a struct instead of an alias. How about I introduced the struct in mr PR instead?

@kickster97 and I wanted this in the mqtt branch, but I guess it's no rush. I think this can be done even better by changing some interfaces to require a BindingKey instead of constructing it everywhere like I did now.

[spuun]

Superseded by #786