Describe the bug

The pfSense GUI supports matching firewall rules on a DSCP value (the dscp config field, rendered as tos <value> in rules.debug), but the FirewallRule model does not define this field. A client that POSTs dscp to /api/v2/firewall/rule receives a 200 and the rule is created — with the dscp value silently discarded.

For policy-routing rules this is hazardous: a rule intended to steer only DSCP-marked traffic to a gateway instead matches all traffic for its interface/protocol, silently re-routing the network.

To reproduce

On pfSense 2.7.2 with pkg-RESTAPI v2.4.0 (reproduced against current master's model, which also lacks the field):

curl -sk -u admin:... -X POST https://<fw>/api/v2/firewall/rule \
  -H "Content-Type: application/json" \
  -d '{"type":"pass","interface":["lan"],"ipprotocol":"inet","protocol":"tcp/udp",
       "source":"any","destination":"any","dscp":"af13","gateway":"MY_GW","descr":"steer af13"}'

Result: HTTP 200; GET of the created rule shows no dscp; pfctl -sr shows the rule without any tos match — it matches all LAN tcp/udp and routes it to MY_GW.

Expected behavior

Either the field is supported (preferred — the GUI supports it) or the API rejects unknown fields instead of accepting-and-discarding them.

Verified fix

Adding a dscp StringField (choices from pfSense's $firewall_rules_dscp_types in guiconfig.inc) to the model resolves it. Patch tested end-to-end on a live pfSense 2.7.2: POST with "dscp":"af11" → field persisted and returned, and the generated rule carries the match (pfctl -sr: ... inet proto tcp all flags S/SA tos 0x28 keep state ...; rules.debug: tos af11).

PR incoming with the model field + a test_dscp case following the test_statetype pattern.