Create sub-quotas for allocation capabilities

[davidchisnall]

The allocator currently deals with static heap quotas. Sometimes it's useful to allow another compartment to allocate memory on your behalf, but not to consume your entire quota. We should allow a mechanism for creating a new quota object that contains part of an existing quota. This should have the same ID as the original, so that objects can be freed in both.

The main complication in this is that, currently, quotas are checked without the allocator lock being held (I think). We need to make sure that the mechanism is robust in the presence of a quota being deallocated during an allocation or deallocation operation.

[hlef]

We are encountering an issue in the network stack which would likely benefit from such a feature.

• Sockets are allocated with the quota of the TCP/IP compartment. See here. This would be hard to change since this allocation and the corresponding free are done deep in the internals of FreeRTOS+TCP.
• To prevent the caller from DoS-ing the TCP/IP compartment by exhausting its quota through creating many sockets without freeing them, we claimed the allocation with the quota of the caller. See here (and the release() which comes a bit later). Thus the caller is accountable for the socket allocation, and would exhaust its own quota in the process.
• Unfortunately this approach does not work, since the caller can always call heap_free_all to remove this claim. The problem would also be there if the caller simply had a much larger quota than the TCP/IP stack.

To address this issue, it would be nice if we could have a mechanism to loan quota: the caller would give enough quota to allocate the socket to the TCP/IP stack, and the loan would be returned when the socket is freed.

This does raise questions on how to refund the quota though:

• The free of the socket happens asynchronously, deep in FreeRTOS+TCP. There is no callback to our code to say that the socket was freed.
• We could refund the quota when closing the socket, and claim it with the TCP/IP stack compartment's quota. If the TCP/IP stack's quota is insufficient we would simply not close the socket. We would thus allow callers to consume some of the stack's quota, but only for a short and rather well-defined amount of time.