I think the perceived impact of this in practice is likely low, the original bf that detected the underlying issue is https://jira.mongodb.org/browse/BF-33804 so it seems like this leak only happens if the router recieves a transaction response with invalid metadata. in fixing this bf we fixed it from being a server crash and now it just leaks a cursor

here https://github.com/mongodb/mongo/blob/73380f5057897d0582567c874643864aca92d453/src/mongo/s/query/establish_cursors.cpp#L223 we call ars->next() but this function can actually throw, if it does we don't add it to the list of remotes to clean and potentially leave an open cursor.

note: ARS::next() is noexcept but CursorEstablisher uses a wrapper that calls an extra function that can throw https://github.com/mongodb/mongo/blob/73380f5057897d0582567c874643864aca92d453/src/mongo/s/multi_statement_transaction_requests_sender.cpp#L146.

we could maybe fix this by having MSTRS not throw and return a host and port or we can just look up all of the hosts and ports in the CursorEstablisher's constructor or something so that we aren't relying on getting back responses from MSTRS to be able to clean up cursors.