MQTT retained message store has no size or count limit and is never reclaimed

Summary

Any authenticated MQTT client with ordinary write permission can retain-publish to unlimited distinct
topics. The retained store has no count or size cap, is held in resident memory, and is never reclaimed;
it survives restart and cannot be enumerated or bulk-purged. Filling it latches the node's memory alarm
permanently, after which no MQTT client can connect at all.

Affected

• deps/rabbitmq_mqtt/src/rabbit_mqtt_retained_msg_store_{dets,ets}.erl
• Requires the rabbitmq_mqtt plugin (not enabled by default)
• Ecosystem: Other: RabbitMQ Package: rabbitmq-server
• Confirmed on 4.3.4. Code unchanged since 6ac8d4def5 (2015-04-23); wider range inferred, not tested.

Mechanism

insert/3 is an unconditional write: no count check, no size check, and no config setting exists to add
one (max_retained and equivalents do not exist anywhere in the plugin or its schema):

insert(Topic, Msg, #store_state{table = T}) ->
  true = ets:insert(T, #retained_message{topic = Topic, mqtt_msg = Msg}),
  ok.

The default DETS backend is opened {ram_file, true}, keeping contents resident.

The store exports only start/insert/lookup/delete/expire/terminate. delete/2 needs an exact topic
name; there is no enumeration, no bulk purge, and no management API or UI surface. The only expiry is
MQTT 5's Message Expiry Interval — client-supplied and optional, so an attacker omits it.

Every comparable store in RabbitMQ has controls this one lac…