LU-3187 ost: check pre 2.4 echo client in obdo validation

Because old echo client still uses o_id/o_seq for objid,
but new echo client will uses FID for the objid. Add
OBD_CONNECT_FID for 2.4 echo client, so 2.4 OST will
convert o_id/o_seq to FID if the request from old echo
client.

Add local flag OBD_FL_OSTID for o_flags to indicate
OST does not support FID yet, then echo client will
still send o_id/o_seq to OST.

cleanup ost_validate_obdo

Test-Parameters: clientjob=lustre-b2_1 clientbuildno=197 testlist=sanity,obdfilter-survey
Test-Parameters: serverjob=lustre-b2_1 serverbuildno=197 testlist=sanity,obdfilter-survey
Signed-off-by: wang di <di.wang@intel.com>
Change-Id: I6001c813b668cf53a66d0d9d74f322bad63765ed
Reviewed-on: http://review.whamcloud.com/6287
Tested-by: Hudson
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Mike Pershin <mike.pershin@intel.com>
LU-3314 scrub: use special fixed FID for .lustre

For lustre-2.x (x <= 3), the ".lustre" has NO FID-in-LMA,
so the client will get IGIF for the ".lustre" object when
the MDT restart.

From the OI scrub view, when the MDT upgrade to Lustre-2.4,
it does not know whether there are some old clients cached
the ".lustre" IGIF during the upgrading. Two choices:

1) Generate IGIF-in-LMA and IGIF-in-OI for the ".lustre".
   It will allow the old connected clients to access the
   ".lustre" with cached IGIF. But it will cause others
   on the MDT failed to check "fid_is_dot_lustre()".

2) Use fixed FID {FID_SEQ_DOT_LUSTRE, FID_OID_DOT_LUSTRE, 0}
   for ".lustre" in spite of whether there are some clients
   cached the ".lustre" IGIF or not. It enables the check
   "fid_is_dot_lustre()" on the MDT, although it will cause
   that the old connected clients cannot access the ".lustre"
   with the cached IGIF.

Usually, it is rare case for the old connected clients
to access the ".lustre" with cached IGIF. So we prefer
to the solution 2).

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: Ifa491850ddab0de0b67aab124dc206ad4f714428
Reviewed-on: http://review.whamcloud.com/6309
Tested-by: Hudson
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Niu Yawei <yawei.niu@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>