Task interaction integrity checks

We have discussed but not implemented several kinds of integrity checks on task interactions. I'm filing this issue to keep track of them and record progress.

The cases I'm aware of are as follows.

Uphill send

Check that SEND is always used from low to high priority. This is one of our mechanisms for avoiding deadlock. Validating this would be relatively cheap (a compare on the send path).

However, there is at least one piece of software that's currently violating the uphill send rule deliberately, and that's the test suite -- specifically, the way the suite and assistant task send back and forth. We could refactor it to fix this, potentially.

However, note that this winds up being a subset of the next thing:

SEND MAC

Impose Mandatory Access Control (MAC) on the SEND operation, limiting the set of tasks that a given task can SEND to. The set would be defined by the application depending on its needs. Tasks outside the set would appear not to exist to the sender, for all intents and purposes -- that is, attempting to access one would be a fault, though it might not specifically be a TaskIndexOutOfRange fault.

Having this can potentially subsume uphill send validation, by ensuring at build time that each task can only send to higher-priority tasks.

Closed RECV reverse MAC validation

A task should only be able to enter closed RECV to listen to a task that could potentially send something. This means we should probably check the SEND MAC information on closed RECV.

REPLY reverse MAC validation

If task A replies to task B, but static MAC rules indicate that B could never have sent a message to A, A is probably malfunctioning. We can detect this case if we have MAC rules. I am inclined to try to detect it, in the interest of catching every programming error as early as possible, but because we must trust servers more than clients in general, I feel like it's slightly less important than (say) validating on SEND.

Post filters

The POST operation does not currently exist, but I'm adding it in #224. This will let any task poke any other task's notifications, simulating interrupts and just generally being a nuisance. (This is why the guidance on interrupt handling is to check the source of truth for the interrupt events instead of simply trusting the notification bits.)

I could imagine a couple of levels of filters here.

1. We could restrict which tasks can access the POST operation in the first place. POST is usually used by specialized servers that simulate interrupts -- the set I'm aware of is the supervisor, the network stack, and the STM32 external interrupt multiplexing driver that @labbott is writing.
2. We could restrict which bits can be posted, either separately or in addition to (1). For instance, we could use the interrupt routing information to generate a "not a hardware interrupt" mask for each task's notification bits, and only allow those to be posted. Or in the extreme we could have ACLs per bit, but that feels too heavy to me.

I currently feel like (1) is the sweet spot there.

The issue covers task SEND, closed RECV, REPLY, and the proposed POST operation in #224, but names no files or tests. Start by locating these task-interaction paths and reviewing their existing access rules. Done requires a decided scope and implemented validation for the selected operations.