Use Vec instead of HashMap for firewall rules, don't paginate

[david-crespo]

As discussed in the 2/4/22 control plane huddle, after working on the firewall rules UI, I found some issues that are orthogonal to and less controversial than the PUT vs. POST debate in #623.

Issues

• Firewall rules are the only collection in the API that we represent as a hashmap instead of a list
• The GET endpoint returns a list but the PUT endpoint expects a hashmap. These should be the same, one or the other.
• The GET endpoint is paginated, which would require the client to pull all the pages before doing a PUT

Fixes proposed here

• Standardize on using a list of rules in both GET response body and PUT request/response body
• Don't paginate GET

[david-crespo]

Maybe this should be called a VpcFirewall and the endpoint should simply be /firewall. That way a Firewall is essentially the name for a collection of rules. I don't see why we would want to have multiple firewalls per VPC, but we don't have to support that. It could just be /vpc/:vpcName/firewall and there is exactly one firewall.

[david-crespo]

functions in this file should return models

[david-crespo]

@rmustacc this change implies a change to RFD 21. Should I open a PR there if this gets merged?

[david-crespo]

I'm going to merge this because it's blocking me on console. I've gotten independent confirmation from @davepacheco and @rmustacc that this approach is good. I will tweak in a followup if necessary.

[rmustacc]

@david-crespo let's get that PR open as that's the main way for us to track the actual bits that we want to have. I'll try to get through the missed discussion to make sure I'm fully up to speed. In the future, I'd prefer to see the RFD updated before we land changes like this so we don't end up churning too much.