When creating a p2p session, let the client choose the Consumer.IPAddress

[pabloxid]

Is your feature request related to a problem? Please describe.
In the process of connecting to a node (on Android), the code starts a p2p session in the createP2PSession() function in manager.go. This sends a p2p message with the topic p2p-session-create. The remote peer returns a SessionResponse inside which there is a Consumer.IPAddress. This IP address is sometimes 10.182.0.2, other times 10.182.1.2, 10.182.2.2, 10.182.3.2 and so on. This is the IP that wireguard_connection_setup is going to assign to the local TUN interface.

For my application I would need this IP to always be the same, or to be able to be chosen from the client side. I don't see the point in this IP being always different, and also unpredictable, and in my case it is very annoying, because it doesn't allow me to share the TUN interface (which on Android is unique) with other tunnel services.

Describe the solution you'd like
Provide a way, a parameter in the p2p-session-create message that allows choosing Consumer.IPAddress from the calling (client) side.

Describe alternatives you've considered
a) always answer p2p-session-create with the same IP in Consumer.IPAddress
b) allow an IP to be selected in the call via a parameter (either the textual IP, or an index, or whatever)
c) document the way this IP is generated, so that it is at least predictable

Additional context
mobile-node, Android

app/core/connection/manager.go:637 Sending P2P message to "p2p-session-create": consumer:{id:"0x9fab7614c785fefa519415f7615323417d01d182" hermesID:"0x80Ed28d76112d8b153bf2F25F0C5C8b1381dE4cf" paymentVersion:"v3" location:{country:"UY"} pricing:{PerGib:"\tM\xc81\xadp\x83V" PerHour:"\x98o\x1dͨ\xfe"}} config:"{"PublicKey":"gekoVBqq42ZKc0HHvvosUgMhe9O+16XNY8+8oMPrBVt=","Ports":null}"

app/core/connection/manager.go:694 Session Response: ID:"43c461f5-8304-4179-8939-2f9bf4946761" PaymentInfo:"v3" config:"{"local_port":0,"remote_port":0,"ports":null,"provider":{"public_key":"oQ/7ZB2Y5GiCHp2DUQkq7tj8w1LkHFHXlTHy67RdE0=","endpoint":"108.221.42.107:48346"}," *consumer":{"ip_address":"10.182.3.2/24* ","dns_ips":"10.182.3.1"}}"

[pabloxid]

I've already figured out why this happens. It's because the remote peer is serving multiple clients at once, and assigning a different subnet to each one. Anyway, with so many IPs available, it wouldn't be unreasonable to allow the client to choose one. If that one isn't available, the request would fail.