When vlan-filtering is off, the switch is operating in vlan-unaware mode, sometimes called vlan-transparent mode. In this mode, the MikroTik CRS304-4XG is ignoring everything but the mac addresses in its learning and forwarding decisions. The ethertype is just part of the payload as far as it is concerned. In this mode the switch will pass all ethernet frames as-is, so it will forward IEEE 802.1Q tagged frames as-is, but it will never add or remove vlan tags. And all ports are "identical", if an ingress frame is received without a tag, the egress frame will be untaggged, regardless of which port(s) it exits on. Likewise, if a frame is received with a tag, it will exit with a tag.
When vlan-filtering is on (vlan-filtering=yes), then the behavior of the switch is fundamentally changed. It will now inspect the first ethertype field to see if has 0x8100 as the ethertype. This is the standard TPID (tag protocol id). If the ethertype is a TPID, then it will examine the following 16 bits, the Tag control information (TCI). and extract the VID from it and the frame will be classified as belonging to the specified vlan. If the extracted VID is zero, or the frame has no tag, then the PVID configured on the port will be used to specify which vlan the frame should be associated with.
Here are the relevant parts of the config with respect to vlan 112
/interface bridge port
add bridge=bridge comment="Access Port to Compute2" ingress-filtering=no interface=ether2 pvid=112
/interface bridge vlan
add bridge=bridge comment=112 tagged=ether1,ether3,ether4,ether5 untagged=ether2 vlan-ids=112
Do you have a serial console you can work from?
If vlan-filtering is turned on from a port that isn't affected (like from the serial console), then I would expect that a PC connected to ether2 that was expecting untagged traffic to be able to communicate with other devices on vlan 112, for example a device connected to ether4 that is tagging vlan 112.
From this statement:
I will assume that the cisco switch has its trunk link port connected to the CRS304 configured with vlan 112 as the native vlan. (is that the "Uplink to Core Sw" via ether1 ?) That would explain how it is "working" when vlan-filtering is turned off, and would also explain why it stopped working when you turned vlan-filtering on; because on the MikroTik you have vlan 112 defined to use tagged frames on all ports except for ether2 (the one connect to "Computer 2" which I will assume is the one you called the "bare metal server").
If you want the trunk to the Cisco to have vlan 112 as the native vlan (on the MikroTik side), you can change your config so it is like this:
/interface bridge port
add bridge=bridge comment="Uplink to Core Sw" interface=ether1 pvid=112
/interface bridge vlan
add bridge=bridge comment=112 tagged=ether3,ether4,ether5 untagged=ether1,ether2 vlan-ids=112
Then ether1 will be a Hybrid link with "native vlan" 112. But then it will no longer pass untagged traffic for vlan 99 between ether1 and (ether3,ether4) (the bridge ports that had pvid set to 99 previously.
Without knowing how the cisco side of the trunk is configured we can't know for sure that my conjecture is true.
What test did you do to determine that the MikroTik was not passing vlan 112 traffic onec vlan filtering was enabled?
I also agree that if you are going to use vlan-filtering (and you will need to if you want full functionality), then you should not be disabling ingress-filtering, that's there to prevent unauthoized vlan traffic from entering a port, and it is the default setting as pointed out by anav.
Until you enable vlan-filtering, just about anything to do with vlans is just ignored, just like a dumb switch would. Ethernet frames that are tagged just appear to be sightly longer (by 4 octets), but no filtering is applied, received frames are forwared just as they were received (with tag if they arrived tagged). And any specification of what frame-types to admit has no effect when vlan-filtering=no.