Searching a maze using DFS and BFS in Python 3
Kill the noise

It's great that the solution works, but it's full of elements that seem to serve no purpose, which makes it confusing and hard to read.


visited_cells is modified but never used
BIT_SOLUTION is defined but never used
A comment like # add 1 to visited cells adds no value to a code like visited_cells += 1. Avoid writing such comments.


The same goes for the # Solve maze ... comments.

The doc comment """ ... """ in solve_bfs is inappropriate. Instead of useful documentation, it's pseudo-code of the implementation. It's unnecessary.
The return statement is unnecessary at the end of a function.
Why write 0b0000 instead of simply 0?


Confusion

I'm confused by the different terminating condition in the two implementations. In one of them, reaching the goal is expressed as cur_cell == len(m.maze_array) - 1, in the other it's current_cell == m.total_cells - 1.
It's best when there's one clear way to do something.
I suggest to change the maze implementation so that the terminating condition can be expressed as m.is_goal(cell_id).

Encapsulation

The posted code is a client of the maze library (I guess your own).
It knows too much about how the maze is implemented.
It's not good that it accesses implementation details such as m.maze_array and m.total_cells.
It's not good that the client knows that the last cell in the implementation is the exit of the maze.
It's not good that the client knows that the cells of the maze are stored in a list (maze_array).
This also limits the kind of mazes that can be modeled.

If you change the maze API so that clients can check if they have reached the exit by calling m.is_goal(cell_id),
then the maze library will be free to place the exit to wherever it likes in its storage,
it wouldn't need to be the last.
The client also wouldn't know what data structure was used to store the cells of the maze,
which again would give the maze library the freedom to use whatever it likes,
and the freedom to change the underlying storage as needed,
for example to something more efficient in a future release.

Style

You can replace len(v) &gt; 0 and len(v) &gt;= 1 with simply v,
because a non-empty collection is truthy in Python.

Instead of while 1:,
it's more natural to write while True:.