[Feature Request]: Add IPFS Loopback Functionality

TL;DR

Some IPFS features don't support interacting with the local node.
Should we fix this?
Should we also add a loopback address e.g. /p2p/self while we're at it?
Create a comprehensive list of affected IPFS commands that could but currently do not support interacting with the local node.

Description

Some IPFS commands/RPCs, when provided with the IPFS peer ID of the local node instead of that of another, result in error messages, whereas others don't produce an error but don't work.

Of course it's debatable whether supporting interacting with localhost is sensible at all.

Here are my main arguments for introducing such features:

we are accustomed to loopback functionality in the world of IP networking
loopback functionality can be useful for primitive and quick testing in various IPFS-applications, to avoid the need of setting up other temporary nodes

Known Examples:

Here are the two kubo commands which I am aware of that do not support interacting with the local node. There may be many other commands that I am not aware of that have the same problem. We should get a comprehensive list of them.

Ping

MY_PEER_ID=$(ipfs id -f="<id>")
ipfs ping $MY_PEER_ID

This produces the following error message: Error: error: can't ping self

LibP2P Stream Mounting:

MY_PEER_ID=$(ipfs id -f="<id>")
ipfs p2p forward /x/loopback-test /ip4/127.0.0.1/tcp/7890 /p2p/$MY_PEER_ID

This command exits normally, and the entry is listed correctly when running ipfs p2p ls.

However, it doesn't work.

Loopback Address

While we're talking about loopback functionality, if we decide to implement loopback functionality to those IPFS commands/RPCs that don't support it but could, it is worth considering whether we should also introduce a dedicated loopback address, similar to the way IP has the localhost name or 127.0.0.0/8 address space as loopback addresses.

Here are some ideas, feel free to come up with other cooler suggestions:

/p2p/self
/p2p/localhost

ipfs / specs