We're using some braindead appliance that insist on having internal
telephone numbers in LDAP, whereas we need to also store external
numbers (external prefix + internal number) for other purposes.

I didn't found any way to dynamically alter the content of the
telephonenumber attribute when asked by the client (filtering the
prefix on the fly), so I quickly opted to store the information twice:
the short and the long number.

The appliance doesn't allow to select which attribute to use, it
always use the first value from telephoneNumber attribute. So the
current solution is to store both values in this attribute, and use the
valsort overlay to always have the short number first. However, this
rely on client being aware of the trick, and using to the second value
when several are available, whereas we'd prefer to do the trick server-side.

I then tried to use different attributes (homePhone vs telephoneNumber)
to store those different values, and use attribute mapping to reply with
the expected value depending on the client. I had a quick look at rwm
overlay, but attribute mapping seems to be global only, not for a given
client only. On Buchan's suggestion, I tried relay backend instead, so
as to only remap attributes values using a specific context.

This seems the correct strategies, however I'm facing a few issues.
First, using a distinct database doesn't allow to provide a virtual view
from a branch in my original database to another branch in the same
database. Meaning, I can't have ou=telephony,dc=myprefix a virtual view
of ou=users,dc=myprefix, I need to use a distinct prefix.

Second, trying the solution at the end of slapo-rwm man page to only map
some attributes and exclude others is actually filtering too much. As
soon as I use 'map attribute *' to exclude unmapped attributes, I can't
list entries anymore. Adding the pseudo-attributes 'entry' to mapped
attributes, which is documented as needed for research operation in
slapd.access man page, doesn't help. So I had to ressort to ACLs instead
to exclude unwanted attribute.

Third, this solution doesn't work currently when trying to sync
the appliance users from ldap. From ldap log, it seems some specific
control is not supported with relay backend:

My wild guess is that the control doesn't survive the context switch
from the original base (dc=msr-inria,dc=inria,dc=fr) to the virtual base
(cn=telephony). Should I report this as a bug, or am I misunderstanding ?