Small status update:

As https://lists.isc.org/pipermail/bind-users/2015-February/094636.html says there's two issues.
1) Mess with "context" for bind/dhcp for both shared and single contexts. In current implementation all signals are masked by all threads but isc_bind9. Q&D solution is to check both of them in while loop and check if we're in main_thread. But this may break other clients. Will discuss with upstream proper approach once I don't have full picture. But with this approach (and epoll disabled (see 2)) both named and dhcpd seems working
In current implementation libisc is very bind oriented and expect dhcp (as well as other "ISC" applications) to run all signal handler on its side. 

2) runtime mechanism for epoll/select switching. This should not be such complicated as (1) as it's matter of few if statements.

Self note:
I've created copr repo to play with modified bind/dhcp 
https://copr.fedorainfracloud.org/coprs/landgraf/dhcp_testing_repo/

"Conflicts: bind99" is added to both bind and dhcp spec files to prevent bind99 libs from installation.
It's in very draft stage and should be discussed with ISC  to avoid conflicts with other applications if any.

Patch for proper signal handling in shared context environment:
https://src.fedoraproject.org/rpms/dhcp/c/e701b476ceed801fe5c921045cb919e2a714039c?branch=master

Socket API in lib/isc/unix/socket.c is a mess. It uses USE_EPOLL by default in bind compilation. Bind99 export library uses USE_SELECT, because it does not define ISC_BIND9. When this define was removed by upstream, socket manager API was not adjusted enough.

Library already offers customization of isc_socket_register() to reset socket manager creation with modified socket manager. Libisc has to simplify way to provide custom implementation of watch_fd(), unwatch_fd(), process_fds(), watcher(). Also usage of isc_socketwait_t and isc__socketmgr_waitevents assumes constant size, but it depends on USE_EPOLL/USE_SELECT. I think we require something similar to isc_socket_register but with only small reimplemented subset offered.

I think there is more significant difference mentioned by upstream for point 1). 

Export libraries are by default built without ISC_BIND9 define. In socket manager in export libraries USE_WATCHER_THREAD was not defined. That meant only single thread was used for sockets handling. However with watcher thread enabled, events about sockets are passed via pipe to worker threads and handled in different threads. I think this is something we want to avoid in dhcp. This is in my opinion more serious problem than USE_SELECT feature. It would require locking across callback functions that was never designed for it. I think USE_WATCHER_THREAD has to be rewritten to be runtime changeable boolean configured at library initialization. select_poke() call behaves different way when watcher thread is used.

I think we should try to rewrite omapi_one_dispatch in omapip/dispatch.c to use isc_socketmgr_waitevents and isc_socketmgr_dispatch. Also return codes match what is required to implement waitevents and dispatch do about the same thing as omapi_one_dispatch/select() does. I think they were intended to be replacement of current select() only implentation. They do exactly the same thing as select in that loop. Handling of socket descriptors would have to be rewritten to use isc_sockfdwatch_t callback to notify socket readiness. isc_socket_fdwatchcreate and isc_socket_fdwatchpoke can be used for that.

If these functions were used instead, usage of epoll/select/whatever would be only internal implementation detail. Application would not require any knowledge about what kind of select mechanism were used. And we would not have to duplicate two different implementations doing the same thing only because we already implement the same thing once again with select() call in dhcp. 
isc_socket_fdwatchcreate() should be called only once per socket creation. However getting io->readfd and io->writefd.

Thank you Petr for investigation. 
I started to think about building export libraries using current sources (as it's done in bind99 fedora package) as backup and safest solution. Export libraries which were built without threads support look good at first glance:
https://copr.fedorainfracloud.org/coprs/landgraf/trepo_export/

The way I've built them is Q&D (spec only change, call configure --disable-threads => copy => sed => make) and configure/makefiles should be adjusted to do it properly instead but so far dhcp functionality works (including failover and signal handling) and regression testing passed. Bind should not be affected.

Unfortunately solution with disabled threads will have limited lifetime. For now it is the best solution available, but ISC already started work on removing possibility to build without threads [1]. For more recent version, we will have to find a bit different way to support DHCP.

[1] https://gitlab.isc.org/isc-projects/bind9/merge_requests/25