UPnP port-mapping leak

[Marcus Lundblad]

When working on jingle file transfers I've come across an issue.

After investigating some further, I've realised libpurple "leaks" UPnP
port mapping leases, appearently my Linksys WRT54GL can only hold 32
forwarding.
As it turns out, we don't issue a delete port mapping action when
finished with using a port (f.ex. for a file transfer).

I can see two solutions:

1) Add a new call "purple_network_remove_port_forwarding" that takes a
fd (gives the port) and protocol (TCP or UDP). The code in network.c
will have to keep track of mapped ports (to determine if there is a
successfull UPnP mapping for a given port).
PRPLs would now call this when done with a stream.
This way PRPLs wont have to deal with UPnP mappings directly, by calling
functions in upnp.h.
It will, ofcourse, add API and PRPLs will have to updated where
appropriate.

2) Let network.c do the "cleanup" on exit (keeping track of port
mappings much the same way as in 1)
This would have the advantage that PRPLs don't need to be updated.
The downside is that port mappings will remain as long as Pidgin is
running.

Any opinions on which would be the best solution?
I would guess the cleanup in 2) would be done anyway, to handle exiting
in the middle of a file transfer, f.ex.

//Marcus