remove to_fasta

Newer BLAST+ packages (2.2.25 onwards at least) do not require query sequence
to begin with a FASTA header.  And SS requires BLAST+ >= 2.2.25 so we can
safely remove `to_fasta` now.

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
port should be specified through -p (or --port) command line option

So config file now contains BLAST specific settings only.  Whereas, port was
meant for the self hosting server.

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
define SequenceServer::Log

So a common logger is accessible to all code nested within SequenceServer.

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
depend on Sinatra 1.3.2

I don't really know if SequenceServer breaks b/w Sinatra 1.2.0 and 1.3.2.
But since I refer to the source code of the latest Sinatra release during
development, it is probably best to depend on the same.

Also, we are going to use features that would break in the next release of
Sinatra, so let's depend on 1.3.2 exact (instead of >= 1.3.2).

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
Rewrite SequenceServer::Blast.

A BLAST search is now evaluated in the context of runtime settings: location of
BLAST+ binaries and databases, and number of threads to use; provided by a
`SequenceServer::Blast` object initialized during startup.

`SequenceServer::Blast#run` executes a BLAST search in the context of the
runtime settings provided by `self`, and returns a
`SequenceServer::Blast::Query` object if the search was successful.

Error encountered, if any, when attempting a BLAST search are wrapped in an
exception object which is caught by `SequenceServer::App`, and propagated to
the user.

A `SequenceServer::Blast::Query` object knows how to validate search
parameters, so we no longer require the `before` block in
`SequenceServer::App`.

Changes in the error handling mechanism resulted in a minor change in how
server communicates error messages to the client: client now expects HTML
formatted error message from the server, instead of plain text.

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>

make blast runtime instance specific

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
Request user to report 500 errors to admin or forum; remove not_found handler.

Any runtime error unless specifically handled is trapped as internal server
error (500) by SS and shown to the user with the full bactrace, requesting them
to report it to the admin of the SS installation or the public forum.

Removed not_found handler since it depended on 500.erb which I tweaked
specifically for 500 (internal server) errors.  Sinatra, in production, shows a
page with heading (and only a heading) "No Found" for 404 errors which is
almost as good as what we previously had :-[.  And we can install a more
helpful 400 page later.

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
client: show network, and server timeout errors

And request users to try again later (since it could be a temporary
network/maintenance issue too; see NOTE), or report to the admin or
forum, if problem persists.

Timeout or network errors previously appeared to the user as "a flicker of
spinner followed by no results or an empty modal", leaving them to figure out
for themselves what exactly happened.  Not good.

NOTE: Detecting timeout errors is tricky.  We can be sure that the response
will be empty if server timed-out.  But empty response can be caused due to
myriad of reasons, broadly referred to as "network issues" later.  Currently SS
assumes empty response to mean timeout or a temporary network issue, and
accordingly displays the error message.  We could try handling network errors
'better' in future.

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
organize error templates

Error sub-view now resides in views/errors.erb, rendered and sent to the user
on the first request (get '/').  Moved 400.erb and 500.erb to views/errors, so
they are referred in the controller as 'errors/400' and 'errors/500'.

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
Switch to a directory based configuration structure.

So it is easier to configure SequenceServer.  We can include shell one liners
on the website that users can simply copy, paste, and run from the command
line.  For example:

Q. How to set number of threads?
A. Run `echo '16' > ~/.sequenceserver/num_threads` in your terminal.

Linux like, yep.

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
Respect num_threads settings.

After this was brought up on the forum [1], I realized SequenceServer never
took into account `num_threads` settings when executing a BLAST search, even
though SequenceServer has had that settings for ages. :no_mouth:.

Thank you Matthias Enders and Robin Kluth.  :smile:.

[1]: https://groups.google.com/forum/?fromgroups=#!topic/sequenceserver/eNP1vmL58D4

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
Split App into App and WebBlast.

Where `App` is the main SequenceServer app responsible for exposing sub-apps
and launching a server (if needed) to host SequenceServer on.  And `WebBlast`
is one of the sub-apps responsible for running BLAST searches over the web.

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
Leverage Sinatra as much as possible to run SequenceServer standalone.

Previously SequenceServer overrode `run!` and `quit!` methods inherited from
`Sinatra::Base` so it could override Sinatra's output.  This caused a lot of
duplication.  Plus we miss out on features added to Sinatra's self-hosting
capabilities.

Instead, let's just extend these methods with the capability SequenceServer
requires, and delegate the rest to `Sinatra::Base`.  Sinatra's output can be
muted by pointing `$stderr` to the null device, and using `STDERR` as the error
stream instead.

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
SS profiles

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
symlink

Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>