How would your endpoint recognize retries for confirmed uplinks, without a frame counter and without the is_retry attribute that is otherwise added for that?
Aside, I’m not part of the core team, so I cannot help here. Also, I would not expect any changes in the current V2 that’s running the community network. For V3, see GitHub - TheThingsNetwork/lorawan-stack: The Things Stack, an Open Source LoRaWAN Network Server
Instead of implementing this, maybe I’d rather have some optional template mechanism (allowing for simple logic, think Handlebars, Mustache) and also allow for tokens in the URL, in the HTTP Integration instead. This would have access to much more data, such as the DevEUI, metadata and gateway data, and even user-defined device attributes.
But I can understand that the team might feel there’s no end to that: next person will ask for some form-urlencoded, throttling, retries, multiple endpoints, double-sided SSL, SOAP headers, … 
The encoded signature is a whopping 101 characters, 94 without the prefix. So if that is a Base58 representation of binary data, then the source for that alone is about 69 bytes? And how are you creating packed_trx? In other words: it seems that the payloads are quite long…?