Ticket 512 - improve performance of vattr code
    
    Bug Description:
    
    	Description of virtual attribute evaluation for a search:
            1 - create a list of candidate
            2 - For each candidate entry the filter is evaluated (slapi_vattr_filter_test).
                For a given filter component, if the attribute is a virtual attribute (it exists a Service Provider for it)
                the computed valueset is cached into the entry "e_virtual_attrs" (slapi_entry_vattrcache_merge_sv).
                The condition to cache the value is that the attribute should be cachable.
            3 - The entries matching the filter are returned
                attributes values are retrieved from "e_virtual_attrs" (slapi_vattr_namespace_values_get_sp),
                if they have been cached
    
    	In DS 389 implementation, only 'nsrole' attribute is cachable. So service provide like 'COS'
    	are not cached. If a filter contains multiple times the same vattr, the vattr is evaluated (cos evaluated)
    	several time. The same way if the set of returned attribute contains a vattr it is evaluated even if
    	it was already evaluated during filter analyze.
    
    Fix Description:
    
    	When a Service Provider evaluates a vattr, the fix consists to provide to the SP a mechanism
    	to say if the returned valueset is or not cachable.
    	If the valueset is cachable, it is stored into the entry (e->e_virtual_attrs).
    	If the vattr is cached and appears several times in the filter or is a returned attribute, then
    	its valueset is looked up from e_virtual_attrs.
    
    	In order to keep the same plugin interface, I added a new value to the buffer_flag parameter.
    	This new value (SLAPI_VIRTUALATTRS_VALUES_CACHEABLE) is not related to buffer but to the fact
    	that the returned valueset is cachable.
    
    	In term of performance, the search throughput is equivalent or better. If the search does not
    	use vattr or use vattr that are evaluate only once, I still measure a gain 5-20%.
    	In the best condition (vattr in the filter/returned and the same vattr appears several times (10))
    	the throughput is > 2times more (1800/s vs 700/s)
    
    ticket: https://fedorahosted.org/389/ticket/512
    
    Reviewed by: Rich Megginson and Noriko Hosoi (thanks Rich, thanks Noriko !)
    
    Platforms tested: Fedora 17
    
    Flag Day: no
    
    Doc impact: no