Validate host and target fields on firewall rules

[charliepark]

If we validate these on the client, they will not hit the API and the user will not have to figure out what these API error messages mean. Note that validating host and target depends on the type selected in the dropdown. The validate function will have to look at the selected type to decide which validation to run. Ideally, changing the type will re-run validation on the value field (I don't think it will work this way by default).

[david-crespo]

These are API errors, so there's not that much we can do about them, or at least, if we were going to spend time getting elaborate client-side it would be better spent on the API side so all clients can benefit.

[david-crespo]

Actually.... the reason this gets to be an API error is because we fail to catch it in client-side validation in the form. So we can probably improve that.

[david-crespo]

Thinking more about this, the validation problem is lessened if we're using comboboxes to pick the VPC, subnet, or instance names (#2065), but because we will not be constraining those fields to values that already exist (the lists are just there to help), we will still have the validation problem.

[charliepark]

Closing this, as we added a number of client-side validation improvements when moving over to comboboxes for firewall rules. All of the examples in the above screenshots are covered by current client-side validations.